Oh, I should also mention that when you get pestered you should click the feedback link and complain. All Google properties should have a feedback link, and the feedback does get noted and acted upon, though the volume precludes individual responses in most cases.
How is ISIS relevant in a discussion about advanced naval warfare? The intersection between regimes able to muster the industrial power to field naval and air forces which require railguns and lasers to oppose and those who publicly burn people alive is empty. That's not a coincidence.
That's not to say diplomacy isn't relevant when discussing ISIS. It definitely is, though it's a different sort. To deal with the likes of ISIS you have to first focus on containing the madness, which requires diplomatic cooperation with surrounding powers, and then you have to identify and address the root causes of the madness (note that Islam is not the root cause; it's merely a convenient hook on which to hang the madness). The US, of course, prefers to try to fight the madmen, ignoring the fact that in this like trying to put out a fire by pumping the bellows.
He didn't, and he's right, and there's nothing wrong with what he's doing.
The key in question isn't a login authentication credential used to access large numbers of machines. It's the key used by Debian systems to verify that they trust software packages from Debian. Note that all Debian software packages are installed as root, and run scripts as root during the installation process. Many Debian software packages include binary code that is run as root during normal usage.
This means that an attacker with the signing key and access to the download servers can create packages that run whatever code he likes on every machine that installs them, as root. If he picks packages that every running Debian system has to have, he can control all well-maintained machines within a few days. That would be hundreds of thousands, maybe millions, of machines, not thousands.
If you're hashing the passwords the length of the password is arbitrary. There is no need to restrict length, except maybe for a minimum size.
If you use bcrypt to hash them, there's a good argument for limiting them to 64 characters, which is that bcrypt will truncate them to 64 characters regardless, so users who use longer passwords aren't getting the benefit they think they are. Unless teh user chooses an insanely weak 65-character password this probably doesn't matter in practice, but I would restrict it just to be sure.
Note that this isn't a reason not to use bcrypt; it's an excellent tunable password hashing algorithm. It just has this one odd restriction.
The same goes for every e-mail provider. Email account access is the crown jewel of online identity, because if I have access to your e-mail I can reset the passwords of all of your other online accounts, including your bank account.
If you're using a short, weak password and not using two-factor on your e-mail because "it's only e-mail"... please think about what other accounts use that e-mail address as their password reset mechanism.
I'm not going to argue about the feasibility. I don't actually know the details of why the GNex can't be upgraded. I could find out (and probably will), but I'm sure I won't be able to share the details, so there's not much point in trying to convince you. I'll just mention that since Android doesn't support blockwise updates, updating GNex requires generating and signing a complete new system image. It's more involved than you're assuming, and therefore there's more scope for it to be problematic.
I don't think there are any technical issues with updating the Nexus S or Nexus One (AFAIK). I think the number of active devices is just too small to justify the updates. But I'm just guessing.
And I know what the official Google line is on the Galaxy Nexus but I'm having a hard time buying it. I'm struggling to understand how a bug at the application layer affecting the browser cannot be fixed because of something to do with lower level firmware.
Pushing an update requires creating and signing a complete new system image. The problem may lie in the signing. I don't know the details.
Google absolutely can update 4.3 to patch the webview vulnerabilities.
So can the OEMs. They don't actually need Google's assistance to fix this. Google absolutely needs theirs. And they won't do it. If they were willing to do updates, they'd move to 4.4.
Currently, your only choice is to get 5.0 or get fucked.
Or 4.4. KitKat's WebView is still in the core OS, but all of the known WebView bugs are fixed in it.
ALL of the OS updating business could be handled by Google offering actual patches that users could install, similar to how every other sane operating system does it
What sort of patches? Source code diffs? How would users install those? Binary patches to binaries built by many third parties with unknown modifications? Google can't create those.
Shoving everything into apps isn't done for security or updatability.
It actually is. Google is remarkably transparent about its goals and intentions. Sometimes I think the level of transparency backfires because everyone assumes there must be something else being hidden. People are so accustomed to assuming that corporations veil their true purposes, but I actually can't think of a case where the internal and external stories differ in any significant respect. And it's not like Google execs could be keeping a lot of stuff from the engineers like me, because we're the ones who actually make all of the key product decisions.
Nor does it reduce fragmentation. Many users refuse to install updates because they drastically alter the functionality and appearance of the apps.
The security upgrades are all in the services app, which has no UI, and maintains backward compatibility. You can update it without updating any of the apps that rely on it, if you don't like the new versions.
I believe Calendar was the latest one - no more weekly view.
The Calendar app has a weekly view. What was removed was the monthly view, but only on small screens where it was useless anyway. Tastes vary, I suppose, but I think the new Calendar app is awesome. In any case, if you don't like Google's calendar, there are a zillion others in the Play store. One of them will likely be to your taste.
Further, users should have full control over the apps and services running on their devices.
I disagree. I completely agree that users should have the option of taking full control over the apps and services running on their devices. This is why all Nexus devices are unlockable, and Google tries in various ways to encourage OEMs to make all their devices unlockable (with very little success, obviously). But making such control the default state is a bad idea because 99.99% of users would be harmed by it, not benefited. A modern operating system is a complex beast and securing it is hard, even without opening the door to random modifications... which may be made by the user or by someone with malicious intentions.
These are difficult and complex issues, but I think the approach Google has taken is a reasonable one: The security model assumes that the device is in a known configuration, and that the build number tells you everything about what's in the system, if it's a standard build. Users who want something else can unlock their devices and install whatever they want, but they are also taking full responsibility for the results.
This is the component that is riddled with security holes in 4.3 and earlier devices, but which Google can't update.
It is news to me that they can't update this component on GSM Nexus devices sold directly by Google without the involvement of a carrier. Last time I checked Google was not updating all the ones which were vulnerable.
See my other reply in this thread regarding the Galaxy Nexus situation. Google would update it if it were possible.
Why not? Google sold me my Galaxy Nexus, they wrote the software. No reason they couldn't update it, they just can't be arsed.
The GNex is a problematic case.
Google actually doesn't write all of the software; even for Nexus devices the SoC manufacturer and device manufacturer provide quite a bit of the low-level stuff needed to make a device boot, and Google doesn't get the source code. For example, I worked on low-level integration for the Nexus 9 and I integrated with a lot of nVidia and HTC code which was provided in binary form only.
In the case of the GNex, the SoC manufacturer (TI) is gone, and it seems that no one has a copy of some of the critical bits of firmware. Google should have foreseen that possibility, and required that the relevant source code be escrowed, or something, but didn't. Such problems can be avoided going forward, but there's nothing that can be done for the GNex.
You mean it is pure coincidence that all the components that get pushed into the play services app are now closed source? (keyboard, location service etc. etc.)
It's not coincidence, but it is a very unfortunate side effect. If we can find a way to fix the core system update issue I think this stuff will get pushed back into the base system.
Semver is a re-branding of an old idea... and the original was slightly better, IMO.
In the original approach, major and minor had the same meanings, but "patch" (AKA subminor) was for changes that are both forward and backward compatible. If the version numbering scheme is applied to a shared library (the context in which this scheme was invented), and you have a program which was written and built against version x.y.z,
The program must be modified and recompiled to run with version x+1.?.?.
The program can run against x.y+1.?, or indeed any version with major version x and a minor number greater than y. However, a program built with x.y.? may not run if dynamically linked with x.y-1.?. That is, changes in minor version number are backward but not forward compatible.
The program can run against any library version x.y.?. Subminor version number changes are forward and backward compatible.
Google has been shoving more and more of the "Android" experience into their apps instead of the OS.
Yep, and for good reason: Because the apps get updated while the OEMs won't update the base system. By moving functionality into the Play services app, Google makes it updatable, reducing fragmentation and enabling security patch distribution. In 5.0, for example, the WebView component was moved out of the system and into the Google apps. This is the component that is riddled with security holes in 4.3 and earlier devices, but which Google can't update.
(Disclaimer: I'm an Android engineer at Google, but my posts contain my own opinions only.)
I didn't try to prove APK wrong. I actually have no interest in arguing with him/her/it. I just find the posts incredibly annoying. I also strongly suspect they're actually paid ads, being compensated for the bit at the end about the "best AV".
They are cutting top performers who are in their 50's and 60's and closing in on the longevity needed for certain insurance and pension benefits.
IBM eliminated their pension plans 20 years ago. Older employees may be more expensive because they've gotten lots of raises throughout their careers, but pensions aren't an issue; IBM's retirement plans are all 401K-based now. IBM actually did what you describe about 10 years ago. The used it to get rid of the people who had been grandfathered into the old pension plan. My former manager got nailed by that as did several other middle managers and execs I knew. I was in the transitional group. They dumped our pensions and instead gave us a one-time payout into a 401K (I got like $80K), plus set up a reasonably-generous 401K matching program, which they later made less generous (though still not bad, honestly).
I suppose older workers may use medical insurance more heavily (like most big companies, IBM is self-insured), but I'd think by their 60's that's actually declining since their kids are no longer on the insurance.
I've been following with interest the debate about government-regulated taxis versus free-market Uber.
One is real and the other one is a lie. There is no such thing as a free market. It's a theory the same way that in physics class you learn Newton mechanics without friction and air resistance and other distracting details.
But in the real world, these things exist. In the real world, no market outside simulations satisfies all the criteria of a free market.
Yes, that's why using your understanding of free market dynamics to understand the real economic world is utterly useless, just like using your understanding of mechanics to understand how real world objects behave is utterly useless.
Except that as it turns out it's actually extraordinarily useful. In both cases. In both cases you do have to make allowances for the ways in which the model doesn't fit reality (or, more precisely, that your simplified version of the model doesn't fit), but in both cases the allowances needed are small, and in many cases negligible.
Look to any country without government regulation on taxis for an idea of what it would be like. Uber has to behave and satisfy certain standards because people are used to them because they've always had them, thanks to government regulation.
Oh, nonsense. For a reasonable comparison you have to look to any country without government regulation and with a low-friction, real-time reputation system. For example, a small village where there's one cab driver and everyone knows him. When I get in a random, unregulated taxi somewhere in South America, I have no way to have any confidence that the driver isn't going to kidnap and ransom me, or at least massively overcharge me (which happens in regulated systems, too, actually), though my experience with such cabs has actually been fairly good. With Uber I actually have a fairly good reason to expect that neither of those things is going to happen, that my ride is an honest business transaction, because Uber knows who the driver is and has an interest in keeping the transaction honest.
Is that as good as regulation? Or better? I don't know. There are pros and cons, and it's probably going to take more time to really map them out. But claiming that it's equivalent to an unregulated, reputationless third-world taxi is just dishonest.
Slashdot Mirror
Oh, I should also mention that when you get pestered you should click the feedback link and complain. All Google properties should have a feedback link, and the feedback does get noted and acted upon, though the volume precludes individual responses in most cases.
True enough. But would that get Google to stop pestering me to set up 2FA?
Yes, because you would have set up 2FA. No need to pester you to do what you've already done.
petulance that has come about from Google's annoying me about the whole thing.
Where do you see this pestering? I'll file a bug; if users are feeling pestered, the security advisories are doing it wrong.
How is ISIS relevant in a discussion about advanced naval warfare? The intersection between regimes able to muster the industrial power to field naval and air forces which require railguns and lasers to oppose and those who publicly burn people alive is empty. That's not a coincidence.
That's not to say diplomacy isn't relevant when discussing ISIS. It definitely is, though it's a different sort. To deal with the likes of ISIS you have to first focus on containing the madness, which requires diplomatic cooperation with surrounding powers, and then you have to identify and address the root causes of the madness (note that Islam is not the root cause; it's merely a convenient hook on which to hang the madness). The US, of course, prefers to try to fight the madmen, ignoring the fact that in this like trying to put out a fire by pumping the bellows.
Plus every cat on the battlefield is going to be chasing it.
Not after they catch it.
Holy Hell, I hope you mistyped something!
He didn't, and he's right, and there's nothing wrong with what he's doing.
The key in question isn't a login authentication credential used to access large numbers of machines. It's the key used by Debian systems to verify that they trust software packages from Debian. Note that all Debian software packages are installed as root, and run scripts as root during the installation process. Many Debian software packages include binary code that is run as root during normal usage.
This means that an attacker with the signing key and access to the download servers can create packages that run whatever code he likes on every machine that installs them, as root. If he picks packages that every running Debian system has to have, he can control all well-maintained machines within a few days. That would be hundreds of thousands, maybe millions, of machines, not thousands.
If you have a smartphone you can use the Google authenticator app.
If you're hashing the passwords the length of the password is arbitrary. There is no need to restrict length, except maybe for a minimum size.
If you use bcrypt to hash them, there's a good argument for limiting them to 64 characters, which is that bcrypt will truncate them to 64 characters regardless, so users who use longer passwords aren't getting the benefit they think they are. Unless teh user chooses an insanely weak 65-character password this probably doesn't matter in practice, but I would restrict it just to be sure.
Note that this isn't a reason not to use bcrypt; it's an excellent tunable password hashing algorithm. It just has this one odd restriction.
The same goes for every e-mail provider. Email account access is the crown jewel of online identity, because if I have access to your e-mail I can reset the passwords of all of your other online accounts, including your bank account.
If you're using a short, weak password and not using two-factor on your e-mail because "it's only e-mail"... please think about what other accounts use that e-mail address as their password reset mechanism.
I'm not going to argue about the feasibility. I don't actually know the details of why the GNex can't be upgraded. I could find out (and probably will), but I'm sure I won't be able to share the details, so there's not much point in trying to convince you. I'll just mention that since Android doesn't support blockwise updates, updating GNex requires generating and signing a complete new system image. It's more involved than you're assuming, and therefore there's more scope for it to be problematic.
LOL.
No, I was right the first time. I simply don't care about hosts vs Adblock or whatever. I just want to stop the crapflooding.
I don't think there are any technical issues with updating the Nexus S or Nexus One (AFAIK). I think the number of active devices is just too small to justify the updates. But I'm just guessing.
And I know what the official Google line is on the Galaxy Nexus but I'm having a hard time buying it. I'm struggling to understand how a bug at the application layer affecting the browser cannot be fixed because of something to do with lower level firmware.
Pushing an update requires creating and signing a complete new system image. The problem may lie in the signing. I don't know the details.
Google actually doesn't see taking it out of open source as a benefit, but a cost. At least, that's the perspective that I see around me.
Google absolutely can update 4.3 to patch the webview vulnerabilities.
So can the OEMs. They don't actually need Google's assistance to fix this. Google absolutely needs theirs. And they won't do it. If they were willing to do updates, they'd move to 4.4.
Currently, your only choice is to get 5.0 or get fucked.
Or 4.4. KitKat's WebView is still in the core OS, but all of the known WebView bugs are fixed in it.
ALL of the OS updating business could be handled by Google offering actual patches that users could install, similar to how every other sane operating system does it
What sort of patches? Source code diffs? How would users install those? Binary patches to binaries built by many third parties with unknown modifications? Google can't create those.
Shoving everything into apps isn't done for security or updatability.
It actually is. Google is remarkably transparent about its goals and intentions. Sometimes I think the level of transparency backfires because everyone assumes there must be something else being hidden. People are so accustomed to assuming that corporations veil their true purposes, but I actually can't think of a case where the internal and external stories differ in any significant respect. And it's not like Google execs could be keeping a lot of stuff from the engineers like me, because we're the ones who actually make all of the key product decisions.
Nor does it reduce fragmentation. Many users refuse to install updates because they drastically alter the functionality and appearance of the apps.
The security upgrades are all in the services app, which has no UI, and maintains backward compatibility. You can update it without updating any of the apps that rely on it, if you don't like the new versions.
I believe Calendar was the latest one - no more weekly view.
The Calendar app has a weekly view. What was removed was the monthly view, but only on small screens where it was useless anyway. Tastes vary, I suppose, but I think the new Calendar app is awesome. In any case, if you don't like Google's calendar, there are a zillion others in the Play store. One of them will likely be to your taste.
Further, users should have full control over the apps and services running on their devices.
I disagree. I completely agree that users should have the option of taking full control over the apps and services running on their devices. This is why all Nexus devices are unlockable, and Google tries in various ways to encourage OEMs to make all their devices unlockable (with very little success, obviously). But making such control the default state is a bad idea because 99.99% of users would be harmed by it, not benefited. A modern operating system is a complex beast and securing it is hard, even without opening the door to random modifications... which may be made by the user or by someone with malicious intentions.
These are difficult and complex issues, but I think the approach Google has taken is a reasonable one: The security model assumes that the device is in a known configuration, and that the build number tells you everything about what's in the system, if it's a standard build. Users who want something else can unlock their devices and install whatever they want, but they are also taking full responsibility for the results.
This is the component that is riddled with security holes in 4.3 and earlier devices, but which Google can't update.
It is news to me that they can't update this component on GSM Nexus devices sold directly by Google without the involvement of a carrier. Last time I checked Google was not updating all the ones which were vulnerable.
See my other reply in this thread regarding the Galaxy Nexus situation. Google would update it if it were possible.
Why not? Google sold me my Galaxy Nexus, they wrote the software. No reason they couldn't update it, they just can't be arsed.
The GNex is a problematic case.
Google actually doesn't write all of the software; even for Nexus devices the SoC manufacturer and device manufacturer provide quite a bit of the low-level stuff needed to make a device boot, and Google doesn't get the source code. For example, I worked on low-level integration for the Nexus 9 and I integrated with a lot of nVidia and HTC code which was provided in binary form only.
In the case of the GNex, the SoC manufacturer (TI) is gone, and it seems that no one has a copy of some of the critical bits of firmware. Google should have foreseen that possibility, and required that the relevant source code be escrowed, or something, but didn't. Such problems can be avoided going forward, but there's nothing that can be done for the GNex.
Out of curiosity, are you still using your GNex?
You mean it is pure coincidence that all the components that get pushed into the play services app are now closed source? (keyboard, location service etc. etc.)
It's not coincidence, but it is a very unfortunate side effect. If we can find a way to fix the core system update issue I think this stuff will get pushed back into the base system.
Semver is a re-branding of an old idea... and the original was slightly better, IMO.
In the original approach, major and minor had the same meanings, but "patch" (AKA subminor) was for changes that are both forward and backward compatible. If the version numbering scheme is applied to a shared library (the context in which this scheme was invented), and you have a program which was written and built against version x.y.z,
The program must be modified and recompiled to run with version x+1.?.?.
The program can run against x.y+1.?, or indeed any version with major version x and a minor number greater than y. However, a program built with x.y.? may not run if dynamically linked with x.y-1.?. That is, changes in minor version number are backward but not forward compatible.
The program can run against any library version x.y.?. Subminor version number changes are forward and backward compatible.
Google has been shoving more and more of the "Android" experience into their apps instead of the OS.
Yep, and for good reason: Because the apps get updated while the OEMs won't update the base system. By moving functionality into the Play services app, Google makes it updatable, reducing fragmentation and enabling security patch distribution. In 5.0, for example, the WebView component was moved out of the system and into the Google apps. This is the component that is riddled with security holes in 4.3 and earlier devices, but which Google can't update.
(Disclaimer: I'm an Android engineer at Google, but my posts contain my own opinions only.)
You've clearly failed at proving apk wrong here http://yro.slashdot.org/commen...
I didn't try to prove APK wrong. I actually have no interest in arguing with him/her/it. I just find the posts incredibly annoying. I also strongly suspect they're actually paid ads, being compensated for the bit at the end about the "best AV".
They are cutting top performers who are in their 50's and 60's and closing in on the longevity needed for certain insurance and pension benefits.
IBM eliminated their pension plans 20 years ago. Older employees may be more expensive because they've gotten lots of raises throughout their careers, but pensions aren't an issue; IBM's retirement plans are all 401K-based now. IBM actually did what you describe about 10 years ago. The used it to get rid of the people who had been grandfathered into the old pension plan. My former manager got nailed by that as did several other middle managers and execs I knew. I was in the transitional group. They dumped our pensions and instead gave us a one-time payout into a 401K (I got like $80K), plus set up a reasonably-generous 401K matching program, which they later made less generous (though still not bad, honestly).
I suppose older workers may use medical insurance more heavily (like most big companies, IBM is self-insured), but I'd think by their 60's that's actually declining since their kids are no longer on the insurance.
Yeah, definitely would need to be regexp-based. Perhaps with crowdsourced updates, to quickly respond to any changes APK makes in his screed.
I've been following with interest the debate about government-regulated taxis versus free-market Uber.
One is real and the other one is a lie. There is no such thing as a free market. It's a theory the same way that in physics class you learn Newton mechanics without friction and air resistance and other distracting details.
But in the real world, these things exist. In the real world, no market outside simulations satisfies all the criteria of a free market.
Yes, that's why using your understanding of free market dynamics to understand the real economic world is utterly useless, just like using your understanding of mechanics to understand how real world objects behave is utterly useless.
Except that as it turns out it's actually extraordinarily useful. In both cases. In both cases you do have to make allowances for the ways in which the model doesn't fit reality (or, more precisely, that your simplified version of the model doesn't fit), but in both cases the allowances needed are small, and in many cases negligible.
Look to any country without government regulation on taxis for an idea of what it would be like. Uber has to behave and satisfy certain standards because people are used to them because they've always had them, thanks to government regulation.
Oh, nonsense. For a reasonable comparison you have to look to any country without government regulation and with a low-friction, real-time reputation system. For example, a small village where there's one cab driver and everyone knows him. When I get in a random, unregulated taxi somewhere in South America, I have no way to have any confidence that the driver isn't going to kidnap and ransom me, or at least massively overcharge me (which happens in regulated systems, too, actually), though my experience with such cabs has actually been fairly good. With Uber I actually have a fairly good reason to expect that neither of those things is going to happen, that my ride is an honest business transaction, because Uber knows who the driver is and has an interest in keeping the transaction honest.
Is that as good as regulation? Or better? I don't know. There are pros and cons, and it's probably going to take more time to really map them out. But claiming that it's equivalent to an unregulated, reputationless third-world taxi is just dishonest.
Can ghostery/adblock do 17 things hosts do for speed, security, & reliability: [...]
The BEST in the antiviruses (MalwareBytes) http://www.av-test.org/en/news... recommend [...]
Does anyone know of an ad-blocking plugin that will block this particularly large, obnoxious and insanely repetitive ad?
I'm seriously thinking about writing one.
I'd even be willing to check a few boxes to mark my interests.
FYI, boxes to check: https://www.google.com/setting...