Note that there's a caveat on the first issue if the author lives/works in California. A chunk of the California Labor Code (sections 2870-2872) spell out the limits of what of an employee's IP a company can claim ownership of in an IP agreement (basically anything done while actually on company time, or that relates directly to what you're paid to do while you're actually employed by them). Any attempt to exceed those limits is illegal and to the extent an agreement purports to exceed those limits it's null and void.
Any California employer is supposed to include a copy of those sections along with any IP agreement. I make a point, when I sign such an agreement, of adding language to the effect of "subject to California Labor Code sections 2870-2872" above my signature if it's not already there.
What I do is have an IMAP server running on a Unix machine, and archive my e-mail into IMAP folders. The server turns those into vanilla Unix mailboxes, so I can deal with the messages as plain text if I want to. Almost every e-mail client out there supports IMAP, so compatibility isn't much of a problem. It also lets me use different clients and different systems to access all my e-mail in one place.
Reading everything, this looks like a minor issue. They're just saying "Mozilla-the-suite is going away. If you want a browser, use Firefox. If you want mail/news, use Thunderbird.". The code isn't going away, if I read it right, just the one-big-suite front-end as a product on it's own.
More like stuffing "home equity loans" on a page about Paris Hilton's sex tape.:)
And why would Google need to keyword-stuff their own pages? They control the rankings, they don't need to cheat to make their own pages appear anywhere they want in their results.
The keywords Google added to their title are limited in number and relevant to the actual page. This is rather different from the practice of a lot of SEOs of stuffing with several dozens of keywords and stuffing keywords that have nothing to do with the content of the page itself. And I notice that a lot of the SEOs squawking about this issue are among the worst offenders for high-volume irrelevant-keyword stuffing. Something to think about.
And I forgot a second catch: at the coffee shop near me, at least half of the users are non-Windows users. Most of the other half use Powerbooks or iBooks and there's a sprinkling of Linux laptops. How does FreeFi deal with non-Windows systems?
The article says these guys run the hotspot at no charge to the location owner "except for the cost of a broadband connection". Does that mean the location owner pays for the link to the Internet? If so then I can see how they can offer this for free, there's no cost to FreeFi at all. And the first question I (and the manager of the coffee shop near me) would ask is, "If I'm paying for the expensive part, why do I need FreeFi at all?".
I'll second the recommendation of others here: block the ads at the DNS level. Windows users need to add entries to their local hosts file. Myself, running Unix at home, I use a three-step approach. First is a very small web "server" running on a scratch server. It's only job is to respond with a "404 Not Found" to any HTTP request (it does SSL and listens on ports 80 and 443). Second, I create a wildcard zone file for BIND that returns the address of my 404 server for any name in or below the zone's root. Third, I modify the named.conf file for the copy of BIND that serves my network, pointing each domain that's a problem (eg. "fastclick.net", "doubleclick.net") to the wildcard zone. Presto, as far as everything on my LAN's concerned any hosts in or under the domains I list now belong to me and my 404 server, not the companies who registered them. This can obviously be worked around by using IP addresses instead of hostnames in URLs in the ad HTML/JS, but nobody's doing that yet and if they do I can deal with it with some appropriate IP-level redirect rules in my firewall.
Advice to obnoxious advertisers: we control the clients, not you. If we don't like what you're doing, we'll do something about it. If you make it too hard to do something about it and won't change your ways, we can make you cease to exist. And with a Linksys router with custom firmware and configuration the non-geeks can get a turnkey solution too.
Even that isn't new. "Boot from known clean write-protected media and scan." was the accepted practice even before stealth viruses were around. We just didn't bother scanning on a possibly-infected system, we went straight to a known-clean boot.
Gee, didn't viruses back in the 80s intercept DOS system calls and block attempts to find them (if something read the file it got the clean version, but the execute-program call got the infected version)? This is why, people, the rule was that you made sure to boot from known clean media before you scanned a system for viruses: you couldn't trust a scan when the malware already had control and could determine what you saw. MS is just realizing that this is still a problem? Someone smack these people with 20-year-old virus summaries.
Because MS's smarttags were part of the OS (see MS's own statements), couldn't be removed and if you wanted Windows you had no choice about getting them. On your laptop, you can easily remove the Google toolbar without affecting anything since it's not part of the OS, and you can get a laptop with Windows from another vendor if this vendor's preinstalled software is that much of a problem.
Re:Not quite the end of the world
on
SHA-1 Broken
·
· Score: 1
The problem is the additions add up. Start with 2^69 operations. Let's assume that takes 100,000 years to perform right now. Refinements in the algorithm might cut 2 off the exponent, reducing the time to one-quarter or 25,000 years. Now, parallelize that onto that 8-way dual-core Opteron. That's 16-way parallelization, so we're now down to less than 1563 years. OK, now let's go the DES/RC5 route, dedicated hardware and massive parallelization. Call it an order of magnitude speed improvement using dedicated ASICs to perform the operations, and we'll go from 16-way to 1024-way parallelization. We're suddenly down to a little over 2 years. Remember that we started at 100,000 years. The reductions in time are divisions, remember, not subtractions.
And yes, generating two documents that have the same hash is an easier problem than generating a document whose hash matches an arbitrary other document. That in turn is easier than the problem of altering a document so it has exactly the same hash as another but retains it's contents. However, they said of the CRC-32 algorithm that you couldn't solve that last problem. Then someone figured out how to solve the first problem with respect to CRC-32, and it was only a couple of years later that we had an algorithm that, given a CRC-32 value and a document, would tell you exactly which 4 bytes of the document to alter to make it have that CRC-32 value. See also similar starts on the MD5 hash.
What we've got here is a better-than-brute-force way of solving that first problem with respect to SHA-1. If previous hash algorithms are any guide, we will see the third problem solved. The only question is when, and history again tells us that it'll happen faster this time than previous times.
Re:Not quite the end of the world
on
SHA-1 Broken
·
· Score: 1
All true, but remember this is only the first cut at the break. A few things to remember:
The algorithm will be refined. It'll get faster and take fewer steps.
The algorithm can probably be parallelized. Even on general-purpose hardware running it in parallel on an 8-way dual-core Opteron rig will let you crack a hash in 1/16th the wall time, and that's not counting dedicated hardware designed for the task and running thousands of units in parallel.
Computing power only increases. Work that takes days now will, in a year or two, take only hours.
If you can find collisions at all in less than the brute-force time, you're well on your way to finding an algorithm that can tweak a specific document to have a given hash. This would, of course, be a complete crack of the hashing algorithm.
In short, if they've found this we need to start worrying and finding a replacement before we hit #4.
I see no problem with this. Now, a bureaucrat might think it odd that the GPS reports I drive one or two miles between fill-ups, and it seems to have real problems getting locks on the GPS satellites, but I'll be happy to keep swapping out those defective GPS units as often as they want to send me new ones.
Those orders for copper foil? Well, I've got some high-clock-speed computers and I need a little extra lining in the cases to keep the RF interference down to legal levels. I wouldn't want the FCC mad at me, now would I?
"Since Google's normal ad service has been declared illegal in France, Google will cease such activities in France. The most technically feasible method of doing this is to make Google's service inaccessible from all IP netblocks assigned to the geographic area of France and any entities based in France who, were they to access Google, would do so under the aegis of French law. In addition we will no longer be accepting ad placement from companies where the transaction would be governed by French law."
Actually Mozilla does have that kind of security system in place. The "capability.policy.*" prefs give you a high degree of control over what things can do. http://www.mozilla.org/projects/security/component s/ConfigPolicy.html starts to cover it, concentrating on JavaScript and DOM accesses. There's no UI yet, mainly because there's no easy way of packaging up what you need to know to make a good decision, but once your local geek's got something he can give you a chunk of text to put in user.js, or a pre-packaged XPI, and you can go ahead and use it without having to know the details yourself.
If replacing characters with different characters with different glyphs is the best counter-argument you can come up with, you've made my point for me quite nicely.
Why should they complain? They have their non-Latin name, including all the non-Latin characters. The only thing they don't have is non-Latin versions of the characters they share with Latin alphabets. Now, if two characters are really two distinct characters, then perhaps the inverse question should be addressed: how to insure that no two distinct characters in Unicode have identical glyphs. Frankly, though, I'd prefer to just say that, where two alphabets share common glyphs they use the same common characters and that's that.
This seems to be more of a bug in Unicode than in the browsers. Unicode has defined multiple character codes as having the exact same glyph. I thought we'd already run into this in Unicode with multiple long representations of the same character, decided it was a bad thing and corrected it by making any representation longer than the shortest illegal. Shouldn't we do the same thing here, and simply make it illegal to have multiple character codes appearing as the same glyph?
I think we have a major disagreement, then. You seem to be arguing that when private companies don't find it profitable to do something, it shouldn't be done by government. I'd argue that government exists precisely to do things that are beneficial to the public but that private companies can't or won't do for whatever reason. If the voters don't want to pay the taxes for it they can make their wrath felt by voting the politicians responsible out of office. More often, though, the voters want the projects to proceed, because that's the only way they're going to get service.
I believe this is, in fact, given a name in the free-enterprise system: competition. If there's a demand for your services that you won't meet, a competitor will. I'm of the opinion that most of the opposition to these projects is of the form "But we don't want to have to compete for customers!".
Except that there's one problem: most of the municipal broadband/wireless projects were started because commercial interests (telcos and cable companies) weren't providing the service, or weren't providing it in the areas it was wanted. Usually this was because they couldn't make as large a profit as they wanted in the areas people wanted the service. It seems not in the public interest to cut people off from access to a service just because the commercial interests don't find them profitable. If the commercial interests don't find that acceptable, perhaps they should re-think their position.
Employee posting on a blog provided and maintained by their employer. Ownership depends solely on the terms the employer imposes. It's exactly like the memos you write at work: they're company property.
Employee posting on a blog they've set up on their own, independently of their employer, but are posting internal, confidential or privileged information about their job. Their employer doesn't own the content, but probably has a say in it because of non-disclosure and other agreements the employee has as part of the terms of their employment.
Employee posting on their own blog and not posting anything work-related. They own the blog free and clear, and their employer has (or should have) only limited ability to do anything based on what's posted (basically the company can legitimately object when the employee posts something in a way that makes them appear to be speaking for the company or in their official capacity). If the company doesn't like it, well... tough, you want to own my time 24 hours a day, pay me for 7 24-hour days a week, not 5 8-hour days.
The original article sounds like it fell into the first category.
It probably won't. Your e-mail client likely remembers your password for you, no? So if your mail client knows the password, what's to stop the Trojan from pulling the password out of where the mail client stored it? And since you're probably using Outlook Express, the Trojan knows exactly where to go. Thank you convenience features.
Yeah, most people look at cookie management from the user's perspective, I get to deal with the other side of it at work is all. I just use the built-in P3P-based options in Mozilla et. al., along with some selective complete blocks and my DNS blocking.
My position on custom-written vs. COTS solutions is pretty much this: "If the problem's in our code, I can fix it. If it's in someone else's binaries, we're SOL.".
If the COTS software exactly fits the problem and has a solid record of not having bugs/problems, it's probably cheaper to use it than to write, debug and maintain your own. On the other hand, most often the COTS software doesn't exactly fit the problem at hand. This is especially true when the problem at hand involves differentiating your offering from everyone else's by doing things differently (hopefully better) than everyone else. In those cases custom-written software at least offers you the opportunity to decide whether it's worth it to make the tweaks. With COTS software it doesn't matter, because beyond the customization built-in you can't change it no matter how much it'd be worth it. Same things with bugs: with custom-written stuff you get to decide whether it's worth it to fix the bug, with COTS it doesn't matter whether it'd be worth it because you can't.
Slashdot Mirror
Note that there's a caveat on the first issue if the author lives/works in California. A chunk of the California Labor Code (sections 2870-2872) spell out the limits of what of an employee's IP a company can claim ownership of in an IP agreement (basically anything done while actually on company time, or that relates directly to what you're paid to do while you're actually employed by them). Any attempt to exceed those limits is illegal and to the extent an agreement purports to exceed those limits it's null and void.
Any California employer is supposed to include a copy of those sections along with any IP agreement. I make a point, when I sign such an agreement, of adding language to the effect of "subject to California Labor Code sections 2870-2872" above my signature if it's not already there.
What I do is have an IMAP server running on a Unix machine, and archive my e-mail into IMAP folders. The server turns those into vanilla Unix mailboxes, so I can deal with the messages as plain text if I want to. Almost every e-mail client out there supports IMAP, so compatibility isn't much of a problem. It also lets me use different clients and different systems to access all my e-mail in one place.
Reading everything, this looks like a minor issue. They're just saying "Mozilla-the-suite is going away. If you want a browser, use Firefox. If you want mail/news, use Thunderbird.". The code isn't going away, if I read it right, just the one-big-suite front-end as a product on it's own.
More like stuffing "home equity loans" on a page about Paris Hilton's sex tape. :)
And why would Google need to keyword-stuff their own pages? They control the rankings, they don't need to cheat to make their own pages appear anywhere they want in their results.
The keywords Google added to their title are limited in number and relevant to the actual page. This is rather different from the practice of a lot of SEOs of stuffing with several dozens of keywords and stuffing keywords that have nothing to do with the content of the page itself. And I notice that a lot of the SEOs squawking about this issue are among the worst offenders for high-volume irrelevant-keyword stuffing. Something to think about.
And I forgot a second catch: at the coffee shop near me, at least half of the users are non-Windows users. Most of the other half use Powerbooks or iBooks and there's a sprinkling of Linux laptops. How does FreeFi deal with non-Windows systems?
The article says these guys run the hotspot at no charge to the location owner "except for the cost of a broadband connection". Does that mean the location owner pays for the link to the Internet? If so then I can see how they can offer this for free, there's no cost to FreeFi at all. And the first question I (and the manager of the coffee shop near me) would ask is, "If I'm paying for the expensive part, why do I need FreeFi at all?".
I'll second the recommendation of others here: block the ads at the DNS level. Windows users need to add entries to their local hosts file. Myself, running Unix at home, I use a three-step approach. First is a very small web "server" running on a scratch server. It's only job is to respond with a "404 Not Found" to any HTTP request (it does SSL and listens on ports 80 and 443). Second, I create a wildcard zone file for BIND that returns the address of my 404 server for any name in or below the zone's root. Third, I modify the named.conf file for the copy of BIND that serves my network, pointing each domain that's a problem (eg. "fastclick.net", "doubleclick.net") to the wildcard zone. Presto, as far as everything on my LAN's concerned any hosts in or under the domains I list now belong to me and my 404 server, not the companies who registered them. This can obviously be worked around by using IP addresses instead of hostnames in URLs in the ad HTML/JS, but nobody's doing that yet and if they do I can deal with it with some appropriate IP-level redirect rules in my firewall.
Advice to obnoxious advertisers: we control the clients, not you. If we don't like what you're doing, we'll do something about it. If you make it too hard to do something about it and won't change your ways, we can make you cease to exist. And with a Linksys router with custom firmware and configuration the non-geeks can get a turnkey solution too.
Even that isn't new. "Boot from known clean write-protected media and scan." was the accepted practice even before stealth viruses were around. We just didn't bother scanning on a possibly-infected system, we went straight to a known-clean boot.
Gee, didn't viruses back in the 80s intercept DOS system calls and block attempts to find them (if something read the file it got the clean version, but the execute-program call got the infected version)? This is why, people, the rule was that you made sure to boot from known clean media before you scanned a system for viruses: you couldn't trust a scan when the malware already had control and could determine what you saw. MS is just realizing that this is still a problem? Someone smack these people with 20-year-old virus summaries.
Because MS's smarttags were part of the OS (see MS's own statements), couldn't be removed and if you wanted Windows you had no choice about getting them. On your laptop, you can easily remove the Google toolbar without affecting anything since it's not part of the OS, and you can get a laptop with Windows from another vendor if this vendor's preinstalled software is that much of a problem.
The problem is the additions add up. Start with 2^69 operations. Let's assume that takes 100,000 years to perform right now. Refinements in the algorithm might cut 2 off the exponent, reducing the time to one-quarter or 25,000 years. Now, parallelize that onto that 8-way dual-core Opteron. That's 16-way parallelization, so we're now down to less than 1563 years. OK, now let's go the DES/RC5 route, dedicated hardware and massive parallelization. Call it an order of magnitude speed improvement using dedicated ASICs to perform the operations, and we'll go from 16-way to 1024-way parallelization. We're suddenly down to a little over 2 years. Remember that we started at 100,000 years. The reductions in time are divisions, remember, not subtractions.
And yes, generating two documents that have the same hash is an easier problem than generating a document whose hash matches an arbitrary other document. That in turn is easier than the problem of altering a document so it has exactly the same hash as another but retains it's contents. However, they said of the CRC-32 algorithm that you couldn't solve that last problem. Then someone figured out how to solve the first problem with respect to CRC-32, and it was only a couple of years later that we had an algorithm that, given a CRC-32 value and a document, would tell you exactly which 4 bytes of the document to alter to make it have that CRC-32 value. See also similar starts on the MD5 hash.
What we've got here is a better-than-brute-force way of solving that first problem with respect to SHA-1. If previous hash algorithms are any guide, we will see the third problem solved. The only question is when, and history again tells us that it'll happen faster this time than previous times.
All true, but remember this is only the first cut at the break. A few things to remember:
- The algorithm will be refined. It'll get faster and take fewer steps.
- The algorithm can probably be parallelized. Even on general-purpose hardware running it in parallel on an 8-way dual-core Opteron rig will let you crack a hash in 1/16th the wall time, and that's not counting dedicated hardware designed for the task and running thousands of units in parallel.
- Computing power only increases. Work that takes days now will, in a year or two, take only hours.
- If you can find collisions at all in less than the brute-force time, you're well on your way to finding an algorithm that can tweak a specific document to have a given hash. This would, of course, be a complete crack of the hashing algorithm.
In short, if they've found this we need to start worrying and finding a replacement before we hit #4.I see no problem with this. Now, a bureaucrat might think it odd that the GPS reports I drive one or two miles between fill-ups, and it seems to have real problems getting locks on the GPS satellites, but I'll be happy to keep swapping out those defective GPS units as often as they want to send me new ones.
Those orders for copper foil? Well, I've got some high-clock-speed computers and I need a little extra lining in the cases to keep the RF interference down to legal levels. I wouldn't want the FCC mad at me, now would I?
"Since Google's normal ad service has been declared illegal in France, Google will cease such activities in France. The most technically feasible method of doing this is to make Google's service inaccessible from all IP netblocks assigned to the geographic area of France and any entities based in France who, were they to access Google, would do so under the aegis of French law. In addition we will no longer be accepting ad placement from companies where the transaction would be governed by French law."
Actually Mozilla does have that kind of security system in place. The "capability.policy.*" prefs give you a high degree of control over what things can do. http://www.mozilla.org/projects/security/component s/ConfigPolicy.html starts to cover it, concentrating on JavaScript and DOM accesses. There's no UI yet, mainly because there's no easy way of packaging up what you need to know to make a good decision, but once your local geek's got something he can give you a chunk of text to put in user.js, or a pre-packaged XPI, and you can go ahead and use it without having to know the details yourself.
If replacing characters with different characters with different glyphs is the best counter-argument you can come up with, you've made my point for me quite nicely.
Why should they complain? They have their non-Latin name, including all the non-Latin characters. The only thing they don't have is non-Latin versions of the characters they share with Latin alphabets. Now, if two characters are really two distinct characters, then perhaps the inverse question should be addressed: how to insure that no two distinct characters in Unicode have identical glyphs. Frankly, though, I'd prefer to just say that, where two alphabets share common glyphs they use the same common characters and that's that.
This seems to be more of a bug in Unicode than in the browsers. Unicode has defined multiple character codes as having the exact same glyph. I thought we'd already run into this in Unicode with multiple long representations of the same character, decided it was a bad thing and corrected it by making any representation longer than the shortest illegal. Shouldn't we do the same thing here, and simply make it illegal to have multiple character codes appearing as the same glyph?
I think we have a major disagreement, then. You seem to be arguing that when private companies don't find it profitable to do something, it shouldn't be done by government. I'd argue that government exists precisely to do things that are beneficial to the public but that private companies can't or won't do for whatever reason. If the voters don't want to pay the taxes for it they can make their wrath felt by voting the politicians responsible out of office. More often, though, the voters want the projects to proceed, because that's the only way they're going to get service.
I believe this is, in fact, given a name in the free-enterprise system: competition. If there's a demand for your services that you won't meet, a competitor will. I'm of the opinion that most of the opposition to these projects is of the form "But we don't want to have to compete for customers!".
Except that there's one problem: most of the municipal broadband/wireless projects were started because commercial interests (telcos and cable companies) weren't providing the service, or weren't providing it in the areas it was wanted. Usually this was because they couldn't make as large a profit as they wanted in the areas people wanted the service. It seems not in the public interest to cut people off from access to a service just because the commercial interests don't find them profitable. If the commercial interests don't find that acceptable, perhaps they should re-think their position.
I see it as a few cases:
- Employee posting on a blog provided and maintained by their employer. Ownership depends solely on the terms the employer imposes. It's exactly like the memos you write at work: they're company property.
- Employee posting on a blog they've set up on their own, independently of their employer, but are posting internal, confidential or privileged information about their job. Their employer doesn't own the content, but probably has a say in it because of non-disclosure and other agreements the employee has as part of the terms of their employment.
- Employee posting on their own blog and not posting anything work-related. They own the blog free and clear, and their employer has (or should have) only limited ability to do anything based on what's posted (basically the company can legitimately object when the employee posts something in a way that makes them appear to be speaking for the company or in their official capacity). If the company doesn't like it, well... tough, you want to own my time 24 hours a day, pay me for 7 24-hour days a week, not 5 8-hour days.
The original article sounds like it fell into the first category.It probably won't. Your e-mail client likely remembers your password for you, no? So if your mail client knows the password, what's to stop the Trojan from pulling the password out of where the mail client stored it? And since you're probably using Outlook Express, the Trojan knows exactly where to go. Thank you convenience features.
Yeah, most people look at cookie management from the user's perspective, I get to deal with the other side of it at work is all. I just use the built-in P3P-based options in Mozilla et. al., along with some selective complete blocks and my DNS blocking.
My position on custom-written vs. COTS solutions is pretty much this: "If the problem's in our code, I can fix it. If it's in someone else's binaries, we're SOL.".
If the COTS software exactly fits the problem and has a solid record of not having bugs/problems, it's probably cheaper to use it than to write, debug and maintain your own. On the other hand, most often the COTS software doesn't exactly fit the problem at hand. This is especially true when the problem at hand involves differentiating your offering from everyone else's by doing things differently (hopefully better) than everyone else. In those cases custom-written software at least offers you the opportunity to decide whether it's worth it to make the tweaks. With COTS software it doesn't matter, because beyond the customization built-in you can't change it no matter how much it'd be worth it. Same things with bugs: with custom-written stuff you get to decide whether it's worth it to fix the bug, with COTS it doesn't matter whether it'd be worth it because you can't.