which will simultaneously make Google Maps work better and improve reCAPTCHA.
I don't know if reCAPTCHA will be improved. It will make it harder, for sure, but it's already dangerously close to the point where it's getting too hard for humans.
Perhaps. I don't have any trouble with reCAPTCHAs. I do with other captcha systems, but Google's seems pretty easy for humans to me. So far.
The only authentication system I have seen that didn't rely on a separate hardware device for authentication that was worth a damn were those that, rather than requiring a selection or inputing what you see on screen, asked a question that only someone family with the topic would know. For example, I've seen engineering bulletin boards ask for the name of a specific type of beam, automotive ones that ask something unique to the marque, etc. so automating a process to gain entry is not practical.
Nonsense. Those are weaker than the general-purpose ones. They draw on knowledge from a relatively obscure area, but it's very unlikely that they have a wide selection of questions/answers. All you need is a knowledgeable human to work his or her way through the question database providing answers for the bot to use, and it's broken. Of course, the value of creating large numbers of fake accounts on such systems is so small that it doesn't matter. Honestly, their goal probably isn't to keep out bots at all, but to make the forum hard for people outside of their target audience to access.
Wouldn't it be neat if Google's very own system was being used to crack their CAPTCHA system?
What's cool is that Google's reCAPTCHA system is being used by Google Maps to improve street address localization, using images of street numbers captured by StreetView cars. People are asked to extract numbers from images that Google's automated number extraction system couldn't get, or wasn't sure about its results. Yes, this means the first few times a given image is presented to a human, the system isn't sure what the correct answer is which means it passes some people/bots it should not, but it also means that to beat reCAPTCHA, you need to build a better, cleverer OCR system for street numbers than Google has.
This means that Google's next step is to get the details from the researchers and use the information to improve its own number-recognition system, which will simultaneously make Google Maps work better and improve reCAPTCHA... at least until the automated system is roughly as good at recognizing street numbers as humans are. That, of course, is the logical conclusion of the captcha race, computers will get better at whatever tasks are presented, until we reach a point that we have no way to distinguish between a bot and a human.
I would like to see a button in Android that disables all Google functions, applications, and connectivity to Google servers.
It's not a single button, but you can do it. Remove any Google account, turn off location services, and disable all of the Google apps, including play services (actually, disabling play services will make most Google apps unable to contact Google, I would expect). You'll also need to turn off Verify Apps, which is rather unfortunate for your device security, but it also relies on Google servers.
Another thing a more technical user could do is to configure a VPN on the device to route all connections to a VPN server you control, then filter connections there. In fact it might be a good idea for someone to disable everything-Google on their device, *and* do that, to see if there's anything left. It would be fairly easy to use the NoGotoFail tool, which uses this strategy to check all connections for security problems (not using SSL, or using it incorrectly) to instead monitor for, and warn for, connections to Google servers. You'd want to check DNS traffic rather than TCP traffic.
That said, it's an interesting idea. Perhaps it should be a more general Android feature: Block all connections to a certain set of IP addresses. Could be used like a hosts file.
The summary says "Employees are awarded varying levels of trust provided they meet minimum criteria". That should say "employee devices...". Employees, of course, do have differing levels of access to various resources, based on the needs of their jobs, with very fine-grained access control. But the criteria-based trust the article is talking about varies based on device, not user. For example, because my phone isn't "fully trusted" (because I don't want to accept the authentication and other requirements that would impose), it can't access the bug report database or the code repositories, but it does have access to the employee directory, my company e-mail and calendar, etc. My laptop is fully trusted because of how it's configured and I can use it to look at anything I'm authorized to see.
The key point, though, is that all of this is completely network-independent. It doesn't matter if I'm connected directly to an internal LAN or sitting in a coffee shop, my access, based on my device and my authenticated identity, is the same. Google does still have VPN infrastructure for some legacy services that haven't been fully migrated to the perimeter-less architecture, but that's being phased out as those services are upgraded or replaced. I only use my VPN client a few times per year, and eventually I need it at all.
And make them with closed stalls. So nobody will know which way the feet are pointing when they take a leak.
This really is the best solution. It addresses all kinds of other issues around families with children, as well as transgender concerns. It even helps with the common problem that one gender's bathroom has a line out the door and down the hall while the other's is mostly empty. Which bathroom is busy and which empty varies depending on location and context, but it's an issue everyone has experienced. When one of the bathrooms is *completely* empty, or when they're small, one-person-at-a-time facilities anyway, people ignore the signs and load-balance intelligently. But most of the time there's just enough traffic in the lightly-used bathroom that that can't be done in a socially-acceptable fashion.
The Lollipop changes... that I'm not sure about. I'm sure it's in the release notes somewhere, but I'd have to go Googling for it, and I'm sure you can do that as well as I can.
Passphrases are better, certainly, but without some significant anti brute force mitigation they're also not going to be secure for long. There are limits to what people can invent and remember, and are willing to enter regularly, and those limits aren't anywhere near the "red giant sun" range... particularly if people have to deal with many different passphrases.
Here in Ontario, Canada, we raised the minimum wage from $10.25 to $11.00, and unemployment went down in the following months and year, from around 7.5 %to 6.75% (source [thestar.com]). While that doesn't prove that minimum wage increases never result in unemployment rises, it does disprove that they always result in unemployment rises.
No, it doesn't disprove that, actually. For all we know, without the minimum wage increase unemployment may have dropped to 6% over the same period. An isolated pair of data points like that can't prove anything.
Although I travel often I am against the pre-check because it seems like a scam to have to pay $85 to be treated like a citizen again.
Sure it is. But take an estimate of the value of your time and multiply it by the amount of time you spend waiting in line. If you travel very much, it's a scam that's well worth what it costs. Though I agree with the many who've recommended doing Global Entry instead. It's what I did.
I fly a lot, and routinely notice that the body scanners take about 5x as long as the metal detectors (and probably cause cancer). I regularly watch the TSA agents clear their backed-up lines by opening the metal detector for 30 seconds, sending 10 people through, and then closing it again (making the value of the scanner clearly questionable).
Not just the scanners. The whole rigamarole of undressing and redressing (shoes, belts, jackets), plus taking laptops and baggies of liquid bottles out, and then putting them all back. Frequent travelers, of course, have all of this down to a science... but frequent travelers are over in the pre-check lane where it's not done, leaving the occasional travelers who have to figure out how to do it all bunched up smelling each others' feet.
I guess their strategy now is to hope that very long security lines encourage more people to sign up for pre, to get into the short, quick line. I suppose it will work eventually.
The revelation that Apple and Google are both receiving many of these requests and have complied on some of them, reversing course only recently, is an important artifact in the narrative.
Note that this may not have been a choice by the companies. As I understand it (IANAL), if the company can comply and can't show any egregious harm that would be caused by compliance, they have to comply or be in contempt of court, and judges have extremely wide latitude in the penalties they can apply for contempt. So the change may have been that security improvements made it impossible for them to comply, or -- as Apple was arguing -- impossible to comply without egregious harm.
On the Google side, for example, one thing that changed was that Google removed the device admin and Android device manager features that allowed the password to be remotely reset. IIRC, the remote reset features were removed in Lollipop. In Marshmallow my team moved password verification into the trusted execution environment. The TEE app (called Gatekeeper) that manages password authentication does allow a "forcible" password change, where the old password is not provided, but higher layers don't offer any way to do this, and doing it will cause the TEE-based crypto keystore to permanently and irrevocably invalidate all authentication-bound keys. Such as the one used for device encryption. So a forcible reset doesn't let you in, it bricks the device (until factory reset).
Previously, device admins could remotely reset passwords so that enterprises could let users into their managed devices when they'd locked themselves out. No more. Now all the admin can do is wipe the device. Android device manager will still allow you to change the password remotely, but you have to provide the old one (and you have to have configured Android device manager on the device, and you have to be able to log into the Google account associated with the phone).
These changes were made to eliminate the potential for abuse by Google, rogue employees, etc. But they had the side effect of making it impossible for Google to comply with password reset requests.
(Disclosure/disclaimer: I'm a Google Android engineer. I work on the TEE-based password manager and crypto keystore. All of the above is publicly available information, however. I tried to avoid expressing any opinions, sticking only to facts. If you find an opinion, however, it's mine and not Google's.)
I'm thinking the password is likely to be much larger than a 20 bit space.
It can be. And I meant to type "40-bit space"... which is still *well* within the realm of what's brute forceable. 20 bits can be searched in under a second on a single machine, depending on the per-try computation required (use of a good password hash algorithm makes it a little harder).
Maybe you won't get up to the true 256 bit space, but it can still be enough to make brute force costs prohibitive.
Less than you might think. Passwords are weak. Very few users actually choose passwords that get anywhere near 40 bits of entropy, and these days you really need closer to 50 bits. And climbing, but as computers get faster users don't get any better at choosing passwords.
No, for real security you can't rely on the password alone. You need something more.
Great news would be Amazon white-listing compliant cables, I have a hard time imaging El Cheapo Cables Inc. being overly concerned about a bullet point in the amazon ToS.
They'll care when Amazon bans them because Benson reported their cable as non-compliant.
Pull the hard drive out, make a copy, and go to town brute forcing it. Done.
I hope they have plans for relocating their brute forcermachines, because the sun is going to become a red giant a blink-of-an-eye into the project.
No, silly, you don't brute force the encryption keys, you brute force the password. Search the 20-bit space, not the 256-bit space.
If what you're describing were practical, then the FBI could have done it with that phone too. They wouldn't have cared about obtaining the hardware-embedded keys, because who needs keys?
The key being burned into the chip means that brute force search of the password space has to be done on the phone (unless you can dig the key out of the chip). The basic idea here is that the disk encryption key is something like a keyed hash of the password, e.g. HMAC(key, password). If you try to brute force the encryption key directly, being enveloped by the expanding sun is an issue. Same if you try to brute force the embedded key. But on the device you can brute force the password... within whatever constraints are applied by the hardware and software on the device. And the hardware will only run signed software.
Why the actual FUCK would you even do what they're offering here instead of just running Ubuntu instead?
Because you like Unix-style CLI tools but have to use Windows for some reason? I see this as potentially a better and less fiddly alternative to Cygwin, and Cygwin definitely makes a lot of sense for those who are forced to use Windows.
But make no mistake: the effectiveness of the security system that we're talking about, is decades behind what we're otherwise used to.
Completely false. Desktop encryption is, in general, far, far inferior to what we have on mobile devices today, because the systems are wide open, which means that the only line of defense is the user's password. Pull the hard drive out, make a copy, and go to town brute forcing it. Done. A small subset of machines these days have a TPM and use it in their encryption, which is better but not hard to fake out. You just have to feed the right sequence of hashes to the device, and it'll do your bidding.
No, mobile devices and mobile OSes are dramatically more secure than desktops and laptops. They use hardware-embedded keys in addition to the user password. When the hardware also enforces brute force rate limiting (as the newer Apple devices do), it's even better.
The one small advantage that machines with full-sized keyboards have is that users are slightly more likely to choose a better password. But only slightly, and hardware performance plus the availability of dirt cheap supercomputing (AWS or GCE) has largely erased that advantage.
You are aware that you are many times more likely to accidentally shoot a member of your family than ever use a gun for defense, are you not?
About twice as likely, not "many times more likely". About 250 criminals are shot to death each year in lawful self-defense shootings, and about 500 people are killed each year by accidental shootings. That also ignores the fact that the vast majority of accidental firearms deaths are due to negligence, and you can make a personal decision not to be negligent with your guns. Gun safety isn't complicate, or hard.
Apple would have told everyone how they flash their chips internally? They would have provided modified binaries that dont increment the bad password counter? Because that is all that was being asked for.
Yes, and yes. Well, Apple wouldn't have done either, but the courts would have done it for them. The right to examine all of the evidence against you implies the right to examine the tools and processes used to gather that evidence. Eventually some court would have ordered the FBI to provide full details to the defense, and it would either come out in the public trial, on the record, or it would have been inadvertently leaked by the defense. Or maybe a copy might have been leaked by an Apple employee for whatever personal reason. Or an FBI employee. Or...
Microsoft, who thinks very clearly and thoroughly over their decisions regarding Windows.
At this very moment, my dad's computer is attempting to download Windows 10 in the background, automatically without asking permission.
He has Dialup internet.
Let that sink in.
Clear and through decisions my ass.
Heh. OTOH, my father in law used a Debian box for years (I set it up for him, after maintaining Windows for him proved to be a Sisyphean task), and I had a similar nightmare trying to keep it updated. I wrote a script that dialed in every night at 1 AM and downloaded for six hours, then disconnected. That clearly didn't work because every now and then a package update came down that was bigger than what could be downloaded in six hours, and completely choked the process. So then I set up a complicated system that got a list of packages needed from the box at his house, sent it to a server I had, which downloaded the packages there, then his box rsynced them. That worked better because if a download didn't complete one night, rsync would resume it the next. That system worked for a while, though the box might go for a few weeks downloading before it had a complete set of updates and could apply them. But eventually the volume of updates grew to the point that it basically never caught up. So, every now and then I downloaded the outstanding packages to a USB stick and took them up to his house.
When I got tired of that, I convinced my wife and her siblings that we should all go in together and buy him a year of broadband (a 5mbit WiMax service). Predictably, when the pre-paid year was up he happily took over paying for the broadband service himself. It cost 3X as much as his dialup had, but was dramatically more useful.
There's a fundamental problem here, and it's not the decision by Windows 10 to download updates automatically. The problem is that modern systems are too big to keep patched over dialup, and, frankly, the Internet is no longer very useful over dialup. Now, I'd hope that Windows 10 offers you an alternative way to deliver updates to it, but the real solution is to get something better than dialup. To be clear, not updating is *not* a viable alternative.
I agree that Linux' success is mostly about licensing, and I think the GPL did play a positive role, but I don't think it's as big as you say. At the time when Linux emerged and started building up steam, BSD existed but wasn't a viable alternative because it wasn't clear who owned it or how it could be legally used. Linux had an overwhelming advantage because its licensing situation was clear.
BSD was eventually freed by the courts in 1994, but by then Linux had already grown an ecosystem of distributions, with lots of great new ideas about how to package, deliver and support software. Some of those ideas were a direct outgrowth of the GPL philosophy, and the GPL on the kernel and the GNU tools helped to set the expectation that virtually everything should be open, so I don't want to understate the GPL's contribution, but I think that BSD could have been in roughly the place that Linux is, if it had actually been available for use and distribution three years earlier. I think we're better off with Linux and the GPL than we would have been with BSD and its license, but BSD could have worked almost as well.
Slashdot Mirror
You nailed it. IDIOTS are pushing this. Void of any comprehension of engineering realities.
Yeah, Siemens and Airbus aerospace engineering teams tend to contain lots of idiots.
Well, either that or slashdot tends to contain lots of arrogant blowhards.
Which is the case here is left as an exercise for the reader.
which will simultaneously make Google Maps work better and improve reCAPTCHA.
I don't know if reCAPTCHA will be improved. It will make it harder, for sure, but it's already dangerously close to the point where it's getting too hard for humans.
Perhaps. I don't have any trouble with reCAPTCHAs. I do with other captcha systems, but Google's seems pretty easy for humans to me. So far.
The only authentication system I have seen that didn't rely on a separate hardware device for authentication that was worth a damn were those that, rather than requiring a selection or inputing what you see on screen, asked a question that only someone family with the topic would know. For example, I've seen engineering bulletin boards ask for the name of a specific type of beam, automotive ones that ask something unique to the marque, etc. so automating a process to gain entry is not practical.
Nonsense. Those are weaker than the general-purpose ones. They draw on knowledge from a relatively obscure area, but it's very unlikely that they have a wide selection of questions/answers. All you need is a knowledgeable human to work his or her way through the question database providing answers for the bot to use, and it's broken. Of course, the value of creating large numbers of fake accounts on such systems is so small that it doesn't matter. Honestly, their goal probably isn't to keep out bots at all, but to make the forum hard for people outside of their target audience to access.
Wouldn't it be neat if Google's very own system was being used to crack their CAPTCHA system?
What's cool is that Google's reCAPTCHA system is being used by Google Maps to improve street address localization, using images of street numbers captured by StreetView cars. People are asked to extract numbers from images that Google's automated number extraction system couldn't get, or wasn't sure about its results. Yes, this means the first few times a given image is presented to a human, the system isn't sure what the correct answer is which means it passes some people/bots it should not, but it also means that to beat reCAPTCHA, you need to build a better, cleverer OCR system for street numbers than Google has.
This means that Google's next step is to get the details from the researchers and use the information to improve its own number-recognition system, which will simultaneously make Google Maps work better and improve reCAPTCHA... at least until the automated system is roughly as good at recognizing street numbers as humans are. That, of course, is the logical conclusion of the captcha race, computers will get better at whatever tasks are presented, until we reach a point that we have no way to distinguish between a bot and a human.
It's a form of the Turing test, I suppose.
It seems that Linux's best chance to take over the desktop is Android.
Or ChromeOS.
I got tired of the perpetual beta aspect, especially when it came to always being a step behind on new hardware integration.
Really? I can think of a few issues with Linux on the desktop, but that hasn't been one of them for a decade or so.
I would like to see a button in Android that disables all Google functions, applications, and connectivity to Google servers.
It's not a single button, but you can do it. Remove any Google account, turn off location services, and disable all of the Google apps, including play services (actually, disabling play services will make most Google apps unable to contact Google, I would expect). You'll also need to turn off Verify Apps, which is rather unfortunate for your device security, but it also relies on Google servers.
Another thing a more technical user could do is to configure a VPN on the device to route all connections to a VPN server you control, then filter connections there. In fact it might be a good idea for someone to disable everything-Google on their device, *and* do that, to see if there's anything left. It would be fairly easy to use the NoGotoFail tool, which uses this strategy to check all connections for security problems (not using SSL, or using it incorrectly) to instead monitor for, and warn for, connections to Google servers. You'd want to check DNS traffic rather than TCP traffic.
That said, it's an interesting idea. Perhaps it should be a more general Android feature: Block all connections to a certain set of IP addresses. Could be used like a hosts file.
The summary says "Employees are awarded varying levels of trust provided they meet minimum criteria". That should say "employee devices...". Employees, of course, do have differing levels of access to various resources, based on the needs of their jobs, with very fine-grained access control. But the criteria-based trust the article is talking about varies based on device, not user. For example, because my phone isn't "fully trusted" (because I don't want to accept the authentication and other requirements that would impose), it can't access the bug report database or the code repositories, but it does have access to the employee directory, my company e-mail and calendar, etc. My laptop is fully trusted because of how it's configured and I can use it to look at anything I'm authorized to see.
The key point, though, is that all of this is completely network-independent. It doesn't matter if I'm connected directly to an internal LAN or sitting in a coffee shop, my access, based on my device and my authenticated identity, is the same. Google does still have VPN infrastructure for some legacy services that haven't been fully migrated to the perimeter-less architecture, but that's being phased out as those services are upgraded or replaced. I only use my VPN client a few times per year, and eventually I need it at all.
Unisex bathrooms.
And make them with closed stalls. So nobody will know which way the feet are pointing when they take a leak.
This really is the best solution. It addresses all kinds of other issues around families with children, as well as transgender concerns. It even helps with the common problem that one gender's bathroom has a line out the door and down the hall while the other's is mostly empty. Which bathroom is busy and which empty varies depending on location and context, but it's an issue everyone has experienced. When one of the bathrooms is *completely* empty, or when they're small, one-person-at-a-time facilities anyway, people ignore the signs and load-balance intelligently. But most of the time there's just enough traffic in the lightly-used bathroom that that can't be done in a socially-acceptable fashion.
The documentation for the hardware-backed keystore is at: https://source.android.com/sec...
The Lollipop changes... that I'm not sure about. I'm sure it's in the release notes somewhere, but I'd have to go Googling for it, and I'm sure you can do that as well as I can.
I take your point. You're right.
That's very unusual on slashdot. Well done, sir. And, BTW, I apologize for inserting "silly" into my earlier post. That was unnecessary.
Now let's try to help. Please stop using the word "password." It's "passphrase." Thanks.
(ObXKCD.)
Passphrases are better, certainly, but without some significant anti brute force mitigation they're also not going to be secure for long. There are limits to what people can invent and remember, and are willing to enter regularly, and those limits aren't anywhere near the "red giant sun" range... particularly if people have to deal with many different passphrases.
Here in Ontario, Canada, we raised the minimum wage from $10.25 to $11.00, and unemployment went down in the following months and year, from around 7.5 %to 6.75% (source [thestar.com]). While that doesn't prove that minimum wage increases never result in unemployment rises, it does disprove that they always result in unemployment rises.
No, it doesn't disprove that, actually. For all we know, without the minimum wage increase unemployment may have dropped to 6% over the same period. An isolated pair of data points like that can't prove anything.
Although I travel often I am against the pre-check because it seems like a scam to have to pay $85 to be treated like a citizen again.
Sure it is. But take an estimate of the value of your time and multiply it by the amount of time you spend waiting in line. If you travel very much, it's a scam that's well worth what it costs. Though I agree with the many who've recommended doing Global Entry instead. It's what I did.
I fly a lot, and routinely notice that the body scanners take about 5x as long as the metal detectors (and probably cause cancer). I regularly watch the TSA agents clear their backed-up lines by opening the metal detector for 30 seconds, sending 10 people through, and then closing it again (making the value of the scanner clearly questionable).
Not just the scanners. The whole rigamarole of undressing and redressing (shoes, belts, jackets), plus taking laptops and baggies of liquid bottles out, and then putting them all back. Frequent travelers, of course, have all of this down to a science... but frequent travelers are over in the pre-check lane where it's not done, leaving the occasional travelers who have to figure out how to do it all bunched up smelling each others' feet.
I guess their strategy now is to hope that very long security lines encourage more people to sign up for pre, to get into the short, quick line. I suppose it will work eventually.
The revelation that Apple and Google are both receiving many of these requests and have complied on some of them, reversing course only recently, is an important artifact in the narrative.
Note that this may not have been a choice by the companies. As I understand it (IANAL), if the company can comply and can't show any egregious harm that would be caused by compliance, they have to comply or be in contempt of court, and judges have extremely wide latitude in the penalties they can apply for contempt. So the change may have been that security improvements made it impossible for them to comply, or -- as Apple was arguing -- impossible to comply without egregious harm.
On the Google side, for example, one thing that changed was that Google removed the device admin and Android device manager features that allowed the password to be remotely reset. IIRC, the remote reset features were removed in Lollipop. In Marshmallow my team moved password verification into the trusted execution environment. The TEE app (called Gatekeeper) that manages password authentication does allow a "forcible" password change, where the old password is not provided, but higher layers don't offer any way to do this, and doing it will cause the TEE-based crypto keystore to permanently and irrevocably invalidate all authentication-bound keys. Such as the one used for device encryption. So a forcible reset doesn't let you in, it bricks the device (until factory reset).
Previously, device admins could remotely reset passwords so that enterprises could let users into their managed devices when they'd locked themselves out. No more. Now all the admin can do is wipe the device. Android device manager will still allow you to change the password remotely, but you have to provide the old one (and you have to have configured Android device manager on the device, and you have to be able to log into the Google account associated with the phone).
These changes were made to eliminate the potential for abuse by Google, rogue employees, etc. But they had the side effect of making it impossible for Google to comply with password reset requests.
(Disclosure/disclaimer: I'm a Google Android engineer. I work on the TEE-based password manager and crypto keystore. All of the above is publicly available information, however. I tried to avoid expressing any opinions, sticking only to facts. If you find an opinion, however, it's mine and not Google's.)
I hope your employer doesn't make you change it every 90 days.
Now, here's the real question: What percentage of users have a password like yours?
I'm thinking the password is likely to be much larger than a 20 bit space.
It can be. And I meant to type "40-bit space"... which is still *well* within the realm of what's brute forceable. 20 bits can be searched in under a second on a single machine, depending on the per-try computation required (use of a good password hash algorithm makes it a little harder).
Maybe you won't get up to the true 256 bit space, but it can still be enough to make brute force costs prohibitive.
Less than you might think. Passwords are weak. Very few users actually choose passwords that get anywhere near 40 bits of entropy, and these days you really need closer to 50 bits. And climbing, but as computers get faster users don't get any better at choosing passwords.
No, for real security you can't rely on the password alone. You need something more.
Great news would be Amazon white-listing compliant cables, I have a hard time imaging El Cheapo Cables Inc. being overly concerned about a bullet point in the amazon ToS.
They'll care when Amazon bans them because Benson reported their cable as non-compliant.
I hope they have plans for relocating their brute forcermachines, because the sun is going to become a red giant a blink-of-an-eye into the project.
No, silly, you don't brute force the encryption keys, you brute force the password. Search the 20-bit space, not the 256-bit space.
If what you're describing were practical, then the FBI could have done it with that phone too. They wouldn't have cared about obtaining the hardware-embedded keys, because who needs keys?
The key being burned into the chip means that brute force search of the password space has to be done on the phone (unless you can dig the key out of the chip). The basic idea here is that the disk encryption key is something like a keyed hash of the password, e.g. HMAC(key, password). If you try to brute force the encryption key directly, being enveloped by the expanding sun is an issue. Same if you try to brute force the embedded key. But on the device you can brute force the password... within whatever constraints are applied by the hardware and software on the device. And the hardware will only run signed software.
Why the actual FUCK would you even do what they're offering here instead of just running Ubuntu instead?
Because you like Unix-style CLI tools but have to use Windows for some reason? I see this as potentially a better and less fiddly alternative to Cygwin, and Cygwin definitely makes a lot of sense for those who are forced to use Windows.
or, there WAS NO HACK and they simply are lying to cover their damned asses
I was talking about the modified firmware the FBI wanted Appy to create, not about whatever Cellbrite allegedly did or didn't do.
But make no mistake: the effectiveness of the security system that we're talking about, is decades behind what we're otherwise used to.
Completely false. Desktop encryption is, in general, far, far inferior to what we have on mobile devices today, because the systems are wide open, which means that the only line of defense is the user's password. Pull the hard drive out, make a copy, and go to town brute forcing it. Done. A small subset of machines these days have a TPM and use it in their encryption, which is better but not hard to fake out. You just have to feed the right sequence of hashes to the device, and it'll do your bidding.
No, mobile devices and mobile OSes are dramatically more secure than desktops and laptops. They use hardware-embedded keys in addition to the user password. When the hardware also enforces brute force rate limiting (as the newer Apple devices do), it's even better.
The one small advantage that machines with full-sized keyboards have is that users are slightly more likely to choose a better password. But only slightly, and hardware performance plus the availability of dirt cheap supercomputing (AWS or GCE) has largely erased that advantage.
You are aware that you are many times more likely to accidentally shoot a member of your family than ever use a gun for defense, are you not?
About twice as likely, not "many times more likely". About 250 criminals are shot to death each year in lawful self-defense shootings, and about 500 people are killed each year by accidental shootings. That also ignores the fact that the vast majority of accidental firearms deaths are due to negligence, and you can make a personal decision not to be negligent with your guns. Gun safety isn't complicate, or hard.
Apple would have told everyone how they flash their chips internally? They would have provided modified binaries that dont increment the bad password counter? Because that is all that was being asked for.
Yes, and yes. Well, Apple wouldn't have done either, but the courts would have done it for them. The right to examine all of the evidence against you implies the right to examine the tools and processes used to gather that evidence. Eventually some court would have ordered the FBI to provide full details to the defense, and it would either come out in the public trial, on the record, or it would have been inadvertently leaked by the defense. Or maybe a copy might have been leaked by an Apple employee for whatever personal reason. Or an FBI employee. Or...
Information is really hard to control.
Microsoft, who thinks very clearly and thoroughly over their decisions regarding Windows.
At this very moment, my dad's computer is attempting to download Windows 10 in the background, automatically without asking permission.
He has Dialup internet.
Let that sink in.
Clear and through decisions my ass.
Heh. OTOH, my father in law used a Debian box for years (I set it up for him, after maintaining Windows for him proved to be a Sisyphean task), and I had a similar nightmare trying to keep it updated. I wrote a script that dialed in every night at 1 AM and downloaded for six hours, then disconnected. That clearly didn't work because every now and then a package update came down that was bigger than what could be downloaded in six hours, and completely choked the process. So then I set up a complicated system that got a list of packages needed from the box at his house, sent it to a server I had, which downloaded the packages there, then his box rsynced them. That worked better because if a download didn't complete one night, rsync would resume it the next. That system worked for a while, though the box might go for a few weeks downloading before it had a complete set of updates and could apply them. But eventually the volume of updates grew to the point that it basically never caught up. So, every now and then I downloaded the outstanding packages to a USB stick and took them up to his house.
When I got tired of that, I convinced my wife and her siblings that we should all go in together and buy him a year of broadband (a 5mbit WiMax service). Predictably, when the pre-paid year was up he happily took over paying for the broadband service himself. It cost 3X as much as his dialup had, but was dramatically more useful.
There's a fundamental problem here, and it's not the decision by Windows 10 to download updates automatically. The problem is that modern systems are too big to keep patched over dialup, and, frankly, the Internet is no longer very useful over dialup. Now, I'd hope that Windows 10 offers you an alternative way to deliver updates to it, but the real solution is to get something better than dialup. To be clear, not updating is *not* a viable alternative.
Licencing.
I agree that Linux' success is mostly about licensing, and I think the GPL did play a positive role, but I don't think it's as big as you say. At the time when Linux emerged and started building up steam, BSD existed but wasn't a viable alternative because it wasn't clear who owned it or how it could be legally used. Linux had an overwhelming advantage because its licensing situation was clear.
BSD was eventually freed by the courts in 1994, but by then Linux had already grown an ecosystem of distributions, with lots of great new ideas about how to package, deliver and support software. Some of those ideas were a direct outgrowth of the GPL philosophy, and the GPL on the kernel and the GNU tools helped to set the expectation that virtually everything should be open, so I don't want to understate the GPL's contribution, but I think that BSD could have been in roughly the place that Linux is, if it had actually been available for use and distribution three years earlier. I think we're better off with Linux and the GPL than we would have been with BSD and its license, but BSD could have worked almost as well.