Doh! Slashdot ate my disclaimer. I had typed the whole thing. Here it is (hopefully complete this time):
(Disclaimer: I'm a Google engineer but I don't work on Chrome, Chromium, ChromeOS or Chromebook. I don't know anything about this stuff other than what I read in the public press.)
This is interesting. Both ChromiumPC and Chomebook are obviously derived from Chromium, ChromeOS and Chrome, which are trademarks owned by Google. If someone trademarks a term derived from my trademark before I create a new trademark derived from my trademark, can that someone really claim that I'm infringing?
I realize this gets complicated by the fact that trademarks are specific to market categories, so it's not infringement to create a derivative (or even duplicate) trademark in a different market space. But the PC space is awfully closely related to the PC operating system space... I would think that Microsoft would stomp all over someone trying to market a WindowsPC brand, and that the courts would support them because it would create market confusion.
In short, to my non-lawyerly eyes, I would think Isys is more at risk of having the court shoot down its ChromiumPC mark than Google is of losing its Chromebook mark.
Maybe the suit is just Isys' way of snagging some free publicity for their product. Heck, for that matter, Google might even be willing to play along for its own share of that free publicity, though that seems very non-Googley to me.
You speak as though deflation is a good thing. It's not.
Borrowing money is very risk in a deflationary economy, which impedes investment and growth. Deflation also makes credit in significant amounts -- e.g. to buy a house -- basically unavailable to ordinary people. Granted that ordinary people badly abuse credit in our world today, but deflation is a cure worse than the disease.
Yes, but does that apply to the source code or to the displayed content?
I just checked, and the answer is in the link provided to you. But I'm not going to tell you what the answer is, because that would be enabling your asshat behavior.
By my reading of the law... it makes no distinction between source or displayed content, but I see nothing in the law that would prohibit a copyright holder from claiming that someone else was the author. Perhaps some other law would, particularly if the claim could be construed as defamation, but I don't see anything in copyright law that addresses this issue.
Ah, you have a separate, trusted, device which signs the amount and destination. Yes, that works. It's not what the GP described, though. The one-time pad approach he mentioned is no defense against a subverted browser. With the signature generated by the secure device, in your case the most a subverted browser would be able to accomplish is to make your transaction fail (denial of service).
Assuming the device is trustworthy and the signature algorithm is properly implemented, of course.
What do you use print preview for? Obviously, previewing before printing, but for what? Does the preview sometimes make you decide you don't really want to print the page? Are you tweaking HTML to get better print formatting on a particular browser?
I can see using preview on word processors, spreadsheets, etc., but printed web pages pretty much are what they are. I've never felt the need to preview, so I'm curious what your use case is.
The only successful attack-vector would be to have an active, complete man in the middle assault within the ongoing HTTPS session, with the ability to process your inputs, change the recipient of the money, and change the output data-stream on the fly without you or the bank software noticing it.
All of which could easily be done by a trojan on your PC, in a thousand different ways. The simplest would be to modify your web browser.
Do these alternatives still track what are you reading? Can they remove content remotely? Do they require you to provide personal data before purchase? If yes on any of those questions, then no, thanks!
With respect to Baen: No, no and no. Well, on the third, you have to pay for the books, so you'll need to provide a CC number or a Paypal account e-mail.
It's worth pointing out that Baen also encourages sharing. Give a copy of your favorite book to a friend! For that matter, Baen has a free "library" where you can download full novels from most of their authors for free (to get you hooked). Many hardcover editions include a CD in the back with dozens of ebooks on it, including all of the previous books in the series of the hardcover, and Baen encourages sharing the contents of the CDs, too. In fact, there are several web sites where you can download the full contents of those CDs -- and Baen not only knows about said sites, they're fine with it.
I think Baen's model is a much better alternative than those proposed by RMS. Baen doesn't worry about sharing or copying, and even encourages it in a lot of ways, because they've discovered that giving books away for free increases sales. They make buying ebooks convenient and fairly cheap, and they don't hassle their customers. The result is that they and their authors make good money and their customers are happy.
try and get a job at Google with out a degree then
I work at Google. My team of about 20 engineers contains three people with PhDs, probably ten with MS degrees, several with BS degrees (some, like me, with multiple BS degrees) and two with no degrees at all, though they did spend some time in a university CS program.
Google doesn't particularly care about degrees. Google's interview process does care a LOT that you have a solid background in algorithms and data structures, and definitely requires that you understand algorithmic complexity. It's unusual -- though hardly impossible -- for someone to acquire that knowledge without formal CS training. You also need to be able to write code, but that skill is easy to obtain without schooling.
All of the level 4 devices on the market include capacitors to smooth power consumption. DPA isn't really an issue. For that matter, even lower-end devices have DPA countermeasures these days. Nor are other side-channels like thermal analysis or EM monitoring, because of the shielding that must encase them in order to provide the physical penetration resistance that is required to meet the level 4 requirements.
For master encryption keys anything other than offline physically secure storage is a risk that is too high
I would agree with you if secure hardware security modules (HSMs) didn't exist. Buy a FIPS 140-2 Level 4 certified device, get people who know what they're doing to configure it for you (including ensuring that the device will never, under any circumstances, export the master keys) and it is acceptable to have the device networked. You still need to have strong physical security around it, though that's more to prevent the DOS attack that results from having the device stolen than due to concern about someone extracting the keys from it, and of course it's always a good idea to secure the network it's on as well just out of due diligence and an abundance of caution, but in such a device your keys are extremely safe from both remote and physical extraction attacks.
With a good HSM, what you really focus your security efforts around isn't physical or network security, it's access control policies. If an attacker can fire requests at the HSM and have them serviced, he doesn't need the keys or physical possession of the HSM, he can just ask the device to encrypt/decrypt/sign whatever he'd like.
When managing keys used to derive other keys (which is probably what is meant by "master key" here, though I didn't RTFA), the most important goals are to ensure that no one, regardless of access, can re-derive and re-export an already-exported key and to carefully control the export and personalization path to ensure that a derived key cannot be duplicated or diverted during personalization. ("Personalization" here refers to the process of loading a derived key into the device that will use it.)
This is all very doable. Obviously, RSA didn't do it, which is baffling.
Good luck brute forcing a 9 character lowercase alphanumeric password
Per yesterday's article, a GPU can test 3.3 million passwords per second. That means the entire space of 9-character lowercase alphanumeric passwords (there are 36^9 of them) can be searched on a single GPU in 356 days, which means that on average it will take 178 days to find a given password with an undirected brute force search. In practice, that can probably be reduced significantly by searching first for dictionary words, combinations of pieces of dictionary words or letter sequences that are "pronounceable".
Brute force searching is also fully parallelizable, so applying 10 GPUs reduces the average time to 18 days (again assuming naive searching -- smarter searching will probably reduce it to 2-3 days).
Throwing in exactly one uppercase letter multiplies the password space by 9, which makes those numbers for one and ten GPUs 1600 and 160 days, respectively. A factor-of-9 improvement may not seem like much, but in this case it moves the problem from the realm of something that can be done in a couple weeks with a few hundred dollars of hardware to something that requires months or thousands of dollars.
Of course you're right that adding a tenth character does more than choosing one uppercase character. But the point is that a 9-character lowercase alphanumeric password is eminently crackable by someone who cares to do it, and at this level every additional multiplier that can be added to the complexity of the brute force attack is useful.
How do you figure that the economy is on Obama's back?
It's not, really, but we're talking about perception here, not reality. The perception is that the economy is always the president's fault, in spite of the fact that (a) the president really has very little power to affect the economy one way or the other and (b) any effects the president's actions have are delayed by so much that it's unlikely that ANY president's policies have significant economic effects during his term of office. The US economy is a supertanker, not a speedboat. You push the rudder over and begin to feel the effects miles/years later.
However, that's not how voters vote. If they're unhappy now, it's the fault of the guy in office now.
But I've seen stuff like this before where the server will only accept specific user agents. If they block firefox 3.5 user agent, but it unofficially works, my suggestion above is a good workaround.
Except that nothing in Google's announcements or their prior actions indicates they're planning to deliberately block older browsers. At most they'll display a warning.
no need to update. simply install the User Agent Switcher plug-in for firefox - and set it to send out a "version 4.0" user agent... and it should probably run fine - at least for a while. As far as the web server is concerned, you'd be running 4.0
Why? It's not like Google Apps is going to start refusing to serve pages to unsupported browsers. They're just not going to promise that their software will continue working properly on unsupported browsers. Deceiving the server about the version your'e using won't fix any bugs in the browser.
FYI, I saw your post and decided to go submit a bug on Google's internal bug tracker for the Google Docs team. Turns out someone else beat me to it, complete with a nice analysis of the precise reason for the breakage in Opera. The bug report was just added today, so it was probably also inspired by your/. post.
I expect the problem will be fixed in a few weeks (not sure what the Docs release cycle is). If you have any other specific issues, post them as well. Google actually does test on Opera, though it's possible that it's not as thorough as for the more widely-used browsers (I don't know -- not my area of expertise).
Linus just realized that version numbers are about marketing more than anything else.
Not a bit. Linus just got tired of the extra baggage of the meaningless 2.6. Under the model they've been using, those numbers will likely never change, so they're just dead weight. They should have been chucked a long time ago, but it took some time to overcome the inertia.
There's a good reason to keep the URL bar - it's a quick and easy way to check for phishing 2 out of 3 times.
For you it does. And for me. For my mom? Not so much. Not only do most non-technical users never even look at the location to check for phishing, but the common phishing trick of mangling the URL so that a naive examination makes it look sorta like it's the right URL nearly always fools most people.
What works better is to have the browser actively checking to see if the site is a known phishing site, or if the link uses any of the phishing URL-mangling tweaks. Is that perfect? No. For technical users, who are capable of understanding the URL and noticing the problems -- and who pay attention -- it's perhaps not even as good. But such users are a tiny fraction of the userbase, and a solution that protects the whole population from most phishing attacks, even if if fails completely some of the time, will stop vastly more attacks than a 100% effective solution that only works for a few people.
Of course, there's nothing preventing the application of both active anti-phishing countermeasures AND the URL bar, but the fact is that the URL bar provides little, if any, useful anti-phishing service for the vast majority of users.
As a current Asterisk 1.6 user, I can attest that it is a piece of junk. It's monolithic, buggy, poorly documented and unwieldy to install from source
Hmm. According to the architecture document, it is not monolithic. Your other complaints may or may not have anything to do with architecture; they're partly about execution and partly about a lack of user focus. It can still be very interesting and useful from an architectural perspective.
The first chapter is on Asterisk. Don't get me wrong, Asterisk has done a lot of good for the open source community, but I shudder to think that anyone would use it as an example of good development
Those revision numbers of yours are huge. I think it'd be easier to remember them if you used alphabetics for the month (e.g. 1.2011.Mar.23.1), but they're still unwieldy. If you want to use a date, I'd much prefer an Ubuntu-style convention. Whether or not you like Ubuntu, the version numbering is very sensible -- enough digits to tell you what you need to know, but few enough that it's very easy to remember. Actually, it might be even better just to use YY.V, where V is incremented with each release and starts over at 0 each Jan 1.
Given the roughly quarterly release cycle, version 3.1 will be out shortly after 3.0 anyway, so even if people are leery of 3.0 that will be a short-lived problem.
Slashdot Mirror
(Disclaimer: I'
Doh! Slashdot ate my disclaimer. I had typed the whole thing. Here it is (hopefully complete this time):
(Disclaimer: I'm a Google engineer but I don't work on Chrome, Chromium, ChromeOS or Chromebook. I don't know anything about this stuff other than what I read in the public press.)
This is interesting. Both ChromiumPC and Chomebook are obviously derived from Chromium, ChromeOS and Chrome, which are trademarks owned by Google. If someone trademarks a term derived from my trademark before I create a new trademark derived from my trademark, can that someone really claim that I'm infringing?
I realize this gets complicated by the fact that trademarks are specific to market categories, so it's not infringement to create a derivative (or even duplicate) trademark in a different market space. But the PC space is awfully closely related to the PC operating system space... I would think that Microsoft would stomp all over someone trying to market a WindowsPC brand, and that the courts would support them because it would create market confusion.
In short, to my non-lawyerly eyes, I would think Isys is more at risk of having the court shoot down its ChromiumPC mark than Google is of losing its Chromebook mark.
Maybe the suit is just Isys' way of snagging some free publicity for their product. Heck, for that matter, Google might even be willing to play along for its own share of that free publicity, though that seems very non-Googley to me.
(Disclaimer: I'
You speak as though deflation is a good thing. It's not.
Borrowing money is very risk in a deflationary economy, which impedes investment and growth. Deflation also makes credit in significant amounts -- e.g. to buy a house -- basically unavailable to ordinary people. Granted that ordinary people badly abuse credit in our world today, but deflation is a cure worse than the disease.
Yes, but does that apply to the source code or to the displayed content?
I just checked, and the answer is in the link provided to you. But I'm not going to tell you what the answer is, because that would be enabling your asshat behavior.
By my reading of the law... it makes no distinction between source or displayed content, but I see nothing in the law that would prohibit a copyright holder from claiming that someone else was the author. Perhaps some other law would, particularly if the claim could be construed as defamation, but I don't see anything in copyright law that addresses this issue.
This raises interesting questions about the .cat TLD.
Not to mention where servers of .xxx domains should be located.
Ah, you have a separate, trusted, device which signs the amount and destination. Yes, that works. It's not what the GP described, though. The one-time pad approach he mentioned is no defense against a subverted browser. With the signature generated by the secure device, in your case the most a subverted browser would be able to accomplish is to make your transaction fail (denial of service).
Assuming the device is trustworthy and the signature algorithm is properly implemented, of course.
What do you use print preview for? Obviously, previewing before printing, but for what? Does the preview sometimes make you decide you don't really want to print the page? Are you tweaking HTML to get better print formatting on a particular browser?
I can see using preview on word processors, spreadsheets, etc., but printed web pages pretty much are what they are. I've never felt the need to preview, so I'm curious what your use case is.
The only successful attack-vector would be to have an active, complete man in the middle assault within the ongoing HTTPS session, with the ability to process your inputs, change the recipient of the money, and change the output data-stream on the fly without you or the bank software noticing it.
All of which could easily be done by a trojan on your PC, in a thousand different ways. The simplest would be to modify your web browser.
Do these alternatives still track what are you reading? Can they remove content remotely? Do they require you to provide personal data before purchase? If yes on any of those questions, then no, thanks!
With respect to Baen: No, no and no. Well, on the third, you have to pay for the books, so you'll need to provide a CC number or a Paypal account e-mail.
It's worth pointing out that Baen also encourages sharing. Give a copy of your favorite book to a friend! For that matter, Baen has a free "library" where you can download full novels from most of their authors for free (to get you hooked). Many hardcover editions include a CD in the back with dozens of ebooks on it, including all of the previous books in the series of the hardcover, and Baen encourages sharing the contents of the CDs, too. In fact, there are several web sites where you can download the full contents of those CDs -- and Baen not only knows about said sites, they're fine with it.
I think Baen's model is a much better alternative than those proposed by RMS. Baen doesn't worry about sharing or copying, and even encourages it in a lot of ways, because they've discovered that giving books away for free increases sales. They make buying ebooks convenient and fairly cheap, and they don't hassle their customers. The result is that they and their authors make good money and their customers are happy.
try and get a job at Google with out a degree then
I work at Google. My team of about 20 engineers contains three people with PhDs, probably ten with MS degrees, several with BS degrees (some, like me, with multiple BS degrees) and two with no degrees at all, though they did spend some time in a university CS program.
Google doesn't particularly care about degrees. Google's interview process does care a LOT that you have a solid background in algorithms and data structures, and definitely requires that you understand algorithmic complexity. It's unusual -- though hardly impossible -- for someone to acquire that knowledge without formal CS training. You also need to be able to write code, but that skill is easy to obtain without schooling.
All of the level 4 devices on the market include capacitors to smooth power consumption. DPA isn't really an issue. For that matter, even lower-end devices have DPA countermeasures these days. Nor are other side-channels like thermal analysis or EM monitoring, because of the shielding that must encase them in order to provide the physical penetration resistance that is required to meet the level 4 requirements.
For master encryption keys anything other than offline physically secure storage is a risk that is too high
I would agree with you if secure hardware security modules (HSMs) didn't exist. Buy a FIPS 140-2 Level 4 certified device, get people who know what they're doing to configure it for you (including ensuring that the device will never, under any circumstances, export the master keys) and it is acceptable to have the device networked. You still need to have strong physical security around it, though that's more to prevent the DOS attack that results from having the device stolen than due to concern about someone extracting the keys from it, and of course it's always a good idea to secure the network it's on as well just out of due diligence and an abundance of caution, but in such a device your keys are extremely safe from both remote and physical extraction attacks.
With a good HSM, what you really focus your security efforts around isn't physical or network security, it's access control policies. If an attacker can fire requests at the HSM and have them serviced, he doesn't need the keys or physical possession of the HSM, he can just ask the device to encrypt/decrypt/sign whatever he'd like.
When managing keys used to derive other keys (which is probably what is meant by "master key" here, though I didn't RTFA), the most important goals are to ensure that no one, regardless of access, can re-derive and re-export an already-exported key and to carefully control the export and personalization path to ensure that a derived key cannot be duplicated or diverted during personalization. ("Personalization" here refers to the process of loading a derived key into the device that will use it.)
This is all very doable. Obviously, RSA didn't do it, which is baffling.
Good luck brute forcing a 9 character lowercase alphanumeric password
Per yesterday's article, a GPU can test 3.3 million passwords per second. That means the entire space of 9-character lowercase alphanumeric passwords (there are 36^9 of them) can be searched on a single GPU in 356 days, which means that on average it will take 178 days to find a given password with an undirected brute force search. In practice, that can probably be reduced significantly by searching first for dictionary words, combinations of pieces of dictionary words or letter sequences that are "pronounceable".
Brute force searching is also fully parallelizable, so applying 10 GPUs reduces the average time to 18 days (again assuming naive searching -- smarter searching will probably reduce it to 2-3 days).
Throwing in exactly one uppercase letter multiplies the password space by 9, which makes those numbers for one and ten GPUs 1600 and 160 days, respectively. A factor-of-9 improvement may not seem like much, but in this case it moves the problem from the realm of something that can be done in a couple weeks with a few hundred dollars of hardware to something that requires months or thousands of dollars.
Of course you're right that adding a tenth character does more than choosing one uppercase character. But the point is that a 9-character lowercase alphanumeric password is eminently crackable by someone who cares to do it, and at this level every additional multiplier that can be added to the complexity of the brute force attack is useful.
How do you figure that the economy is on Obama's back?
It's not, really, but we're talking about perception here, not reality. The perception is that the economy is always the president's fault, in spite of the fact that (a) the president really has very little power to affect the economy one way or the other and (b) any effects the president's actions have are delayed by so much that it's unlikely that ANY president's policies have significant economic effects during his term of office. The US economy is a supertanker, not a speedboat. You push the rudder over and begin to feel the effects miles/years later.
However, that's not how voters vote. If they're unhappy now, it's the fault of the guy in office now.
Actually, it's robbery not theft.
That's a good point. Robbery is a much more serious crime than mere theft.
Salt makes it a non-issue when used correctly.
Sufficient salt defeats rainbow tables, but doesn't change the fact that most user-chosen passwords are crackable without tremendous effort.
But I've seen stuff like this before where the server will only accept specific user agents. If they block firefox 3.5 user agent, but it unofficially works, my suggestion above is a good workaround.
Except that nothing in Google's announcements or their prior actions indicates they're planning to deliberately block older browsers. At most they'll display a warning.
no need to update. simply install the User Agent Switcher plug-in for firefox - and set it to send out a "version 4.0" user agent... and it should probably run fine - at least for a while. As far as the web server is concerned, you'd be running 4.0
Why? It's not like Google Apps is going to start refusing to serve pages to unsupported browsers. They're just not going to promise that their software will continue working properly on unsupported browsers. Deceiving the server about the version your'e using won't fix any bugs in the browser.
FYI, I saw your post and decided to go submit a bug on Google's internal bug tracker for the Google Docs team. Turns out someone else beat me to it, complete with a nice analysis of the precise reason for the breakage in Opera. The bug report was just added today, so it was probably also inspired by your /. post.
I expect the problem will be fixed in a few weeks (not sure what the Docs release cycle is). If you have any other specific issues, post them as well. Google actually does test on Opera, though it's possible that it's not as thorough as for the more widely-used browsers (I don't know -- not my area of expertise).
Linus just realized that version numbers are about marketing more than anything else.
Not a bit. Linus just got tired of the extra baggage of the meaningless 2.6. Under the model they've been using, those numbers will likely never change, so they're just dead weight. They should have been chucked a long time ago, but it took some time to overcome the inertia.
There's a good reason to keep the URL bar - it's a quick and easy way to check for phishing 2 out of 3 times.
For you it does. And for me. For my mom? Not so much. Not only do most non-technical users never even look at the location to check for phishing, but the common phishing trick of mangling the URL so that a naive examination makes it look sorta like it's the right URL nearly always fools most people.
What works better is to have the browser actively checking to see if the site is a known phishing site, or if the link uses any of the phishing URL-mangling tweaks. Is that perfect? No. For technical users, who are capable of understanding the URL and noticing the problems -- and who pay attention -- it's perhaps not even as good. But such users are a tiny fraction of the userbase, and a solution that protects the whole population from most phishing attacks, even if if fails completely some of the time, will stop vastly more attacks than a 100% effective solution that only works for a few people.
Of course, there's nothing preventing the application of both active anti-phishing countermeasures AND the URL bar, but the fact is that the URL bar provides little, if any, useful anti-phishing service for the vast majority of users.
As a current Asterisk 1.6 user, I can attest that it is a piece of junk. It's monolithic, buggy, poorly documented and unwieldy to install from source
Hmm. According to the architecture document, it is not monolithic. Your other complaints may or may not have anything to do with architecture; they're partly about execution and partly about a lack of user focus. It can still be very interesting and useful from an architectural perspective.
The first chapter is on Asterisk. Don't get me wrong, Asterisk has done a lot of good for the open source community, but I shudder to think that anyone would use it as an example of good development
What's bad about it?
Those revision numbers of yours are huge. I think it'd be easier to remember them if you used alphabetics for the month (e.g. 1.2011.Mar.23.1), but they're still unwieldy. If you want to use a date, I'd much prefer an Ubuntu-style convention. Whether or not you like Ubuntu, the version numbering is very sensible -- enough digits to tell you what you need to know, but few enough that it's very easy to remember. Actually, it might be even better just to use YY.V, where V is incremented with each release and starts over at 0 each Jan 1.
Given the roughly quarterly release cycle, version 3.1 will be out shortly after 3.0 anyway, so even if people are leery of 3.0 that will be a short-lived problem.