I delegate creating passwords to PasswordSafe. The current standard policy is 15 characters, requires at least 2 lowercase letters, 1 uppercase letters, at least 1 symbol. The password database is backed up and available to my devices via a server I control. I've been steadily increasing the password length as hardware improves.
I can't believe that changing the client to use HTTPS URLs when checking for and downloading updates would disrupt the rest of the Web site that badly. And as far as users using HTTPS to browse the site, that shouldn't affect ads unless the ad networks are incapable of serving content via HTTPS. In this day and age, that should be an issue for only the most incompetent of ad networks.
I learned to code first in classes in high school (BASIC, FORTRAN, COBOL, Pascal) and then by reading the relevant books or documentation (C, C++, Lisp, Icon, Java, C#, Perl, Python, Ruby, PHP, Javascript et. al.).
The more interesting question is where developers first learned to program (a completely different skill from coding). IMO we don't need to teach children to code, we need to teach them to program. Which means first teaching them to approach problems logically and analytically, which is going to cause the loss of about 75% (my guesstimate) of the educational establishment when they can't deal with students who know how to analyze material, do independent research and call teachers on incorrect classroom material.
The liability isn't being created by user-posted content in this case. It stems from the site actually knowing about the actions of some users and failing to give notice when it could foresee that that failure would put other users at risk. It's the same principle that says that if I know of a danger on my property and fail to post notice of it or take steps to keep people out I'm liable if someone gets hurt by it. Section 230 never comes into play.
The big threat isn't that, it's a vulnerability in a server program on the zwave network that provides data from the devices that can be exploited to let you execute code on that device. Now you can load a program onto it that, rather than doing it's normal job, can connect to any of the PCs that can see that data. The PCs will see an internal connection which bypasses the router's firewall and quite possibly the PC's individual firewall if like most people you've told your PCs they're on a home network and can trust other local computers. Being able to do that only if you already have access to the inside of the house isn't particularly risky, the set of potential attackers is pretty limited. Being able to do that via WiFi, OTOH, means anybody driving by on the street could attack you and that's a whole 'nother order of risk.
Proper setup for IoT: wired networking (via powerline is probably the easiest), no WAN access. Vulnerabilities can still be exploited, but the attacker has to be inside your house to do it. A compromised PC could be used to stage an attack, but if they're compromised your PC they can control the devices directly if those are the targets and if the PC's the target they don't need to compromise the devices at that point.
For the wireless fans, I have bad news: there isn't any safe way to access IoT devices over WiFi. The connectivity-at-a-distance nature and lack of interface to configure encryption/authentication keys on the devices makes it inherently impossible.
I'd love to see IBM take a swing at this one, seeing as the original decision that allowed non-IBM PC-compatible machines to be created turned on the question of whether creating a BIOS that exposed the exact same interface as IBM's BIOS infringed on IBM's copyright if all other code could be proven to be entirely original. Under this decision the answer would be "Yes.", and IBM would be owed damages for every single PC created using a non-IBM BIOS that had any trace of the legacy BIOS API in it (at a minimum every BIOS that wasn't completely UEFI-only).
It might also be entertaining to analyze the effects of this ruling on Oracle's use of GPL- and LGPL-licensed glibc and kernel header files in their products that run on Linux. Neither license quite directly addresses the question of copying copyrighted API declarations into object files and executables. They address linking of various sorts, and copying into source code, but this particular aspect's deemed outside the scope of the license and thus not addressed.
It sounds like this method doesn't identify bugs, it identifies sections of code where the programmer was under stress. Those are likely candidates for sections of code where bugs can occur, but the developer likely already knew that. It doesn't help at all in figuring out exactly what errors there are in that stretch of code, and it won't help in deciding where to test because you should already be testing all the code. If you aren't, you've got bigger problems than merely bugs in the code and you likely won't be taking advantage of this technique either. Basically, it's yet another management idea that sounds good but doesn't fix the actual problem.
Better yet, use a password which gives more combinations than a PIN code. As for storing information, Android does include that functionality in the form of device encryption. You have to enable it, but it's certainly there. Communication... S/MIME encryption should already be supported by the email app and doesn't require any intermediate servers to know your key.
For real-time chat 3rd-party apps are the only solution. I'm still looking for one based around x.509/SSL certificates, though. I don't trust home-baked encryption and none of the apps out there seem to want to discuss the details of what's underneath their promises.
He probably shouldn't be allowed to sue for that much, but then large rightsholders shouldn't be allowed to sue for the ridiculous amounts they sue for either. No matter, whether he should be allowed to or not, the law says that's what he can sue for since they infringed on his copyrights. Those are the rules the big corporations and rightsholders made, I don't see any reason why this photographer shouldn't play by them.
The original set of emojis worked nicely for incorporating emotional and attitude markers into otherwise emotionless text. I think we do need something like that in Unicode. The current set, though, goes way too far beyond that and needs to be mercilessly pruned back. Unicode is not supposed to be a way to incorporate every single image anyone could want as a single character. Trim it back and use images for images. To quote someone, "If you're trying to design a hammer that can turn screws, it's time for you to put the hammer down and go get a screwdriver.". OK, it's not an exact quote, but I can't do justice to the interspersed expletives in the original.
I've experienced the bias against older tech workers. I've also seen the results of that bias: work that would've gotten a failing grade even in the college courses I took, let alone at some of my employers. There's a considerable advantage to having been there, done that, can see how current problems match previously encountered problems and what methods already exist to solve them. To give an extreme example, traditional Web applications (most logic on the server, Javascript in the client is used primarily for input validation and display formatting) mirror very closely the flow of ancient 3270 workstation "green-screen" applications: the server sends a block of display and validation instructions to the client, the user enters the data without interacting with the server, the client sends the completed form back to the server as a single block for processing. The same flow held for the forms applications I build for DEC VAX/VMS in the 80s. And many of the tricks developed to maintain session data across requests for web application are the same tricks we used for the same purpose way back when. I can see the same pendulum swing at work as well: 3270 workstations gave way to interactive terminals (where the application could directly interact with the user), which gave way to forms applications, which gave way to thick clients (PC applications that accessed remote servers via various protocols), which in turn gave way to Web applications, which are now giving way to thick clients again (this time Javascript framework applications running in the browser accessing remote servers via XML/JSON and RESTful interfaces). That perspective gives me a big advantage in knowing where to go for things that already exist and have had all the kinks thoroughly worked out that I can apply to the current problem, rather than having to work solutions out from first principles or copy-and-paste code from StackOverflow as a black box as many of the younger developers do.
Most of the bias I attribute to a mistaken belief that "old" = "unable/unwilling to learn". Some of that belief probably comes as a reaction to the normal skepticism older people have to the latest "silver bullet" sales hype. We've seen those fail to live up to the hype time and time again, someone who's only been in the business 5 years and who hasn't maintained a single application through many update cycles hasn't gotten the first-hand experience with the fallout. It's not that the shiny new tech isn't good, but the salesman is probably over-promising to try and seal the deal and I'd prefer to find the gotchas in a test project rather than by having production fall over.
For AR I don't expect the phone to be the display. As I said, something like Google Glass which uses the phone as the processing and communications unit and simply displays on effectively your entire field of view. No need to bind the phone permanently to the display, because displays will improve (just like right now we don't bind the phone permanently to a headset, we connect them via Bluetooth and we can replace the headset with a better model without needing to replace the phone in the process).
The whole idea that people are inherently lazy and won't work without being forced to always puzzled me. Most of the people I know want to do something productive, but more often than not it's either not something they can get enough income from quickly enough to be able to drop their day job and start doing it full-time or it's not something they can get enough income from to keep the bills paid. Give them a guaranteed basic income and they won't sit around doing nothing, they'll start doing what they want to do (instead of the day job they have to have because it pays the bills).
And on the flip side, what does Donald Trump do exactly? I know he's rich and considered successful, but what work does he actually do? Or Kim Kardashian? It always seemed to me that the more successful you were, the more well-off you were, the less actual work you appeared to do each day. I know there's research involved in say running a major investment fund like Warren Buffet does, but he doesn't do the majority of it. 95% is delegated out to subordinates who do the legwork and write up the analyst reports, Buffet himself just goes over those reports and makes the final decisions. It's something only he can do, but he's not spending 40 hours a week nailed down to a desk poring over corporate reports and newspaper articles and stock trade data, running spreadsheet calculations to figure out what's behind the stock movements and what's likely to happen in the future.
To quote a mill supervisor, "I don't want the industrious guy who'll clean up the mess with a smile. I want the lazy bastard who'll figure out how to stop the mess from happening so he doesn't have to clean it up all the time.".
I don't think we've hit peak smartphone, but we're at a plateau. The next steps will be three things:
1. Reduced cost and improved durability, bringing smartphones to those areas of the world that currently can't afford them.
2. Improved battery life. That's going to come from battery tech, not the phone side.
3. Augmented reality. Not virtual reality, but something like Google Glass that can use the entire surface of the lens as a display instead of just a small chunk in a corner.
There are inserts that fit the Keurigs that you can fill with your own ground coffee, then empty after it's brewed. I'd love to use them, it'd give me a wider variety of coffees. The only problem is that none of them seal properly, water and grounds come out the top and make a mess and the leakage interferes with the brewing. If Keurig really wanted to solve the problem, put the research into modifying the MyK-Cup so it seals properly and the water flows through the grounds rather than off the top and through the open mesh screen.
If they have access to the PC, all they have to do is wait for the user to log in to Google themselves, then use that session for their purposes. No need at all to wait for an unattended browser.
The idea is that it won't matter whether you have 2FA turned on or not, you've already authenticated to your Google account and your compromised browser can then use it's access to that account to push the malicious app to your phone and activate it. 2FA can't protect you from that because the malicious code starts after you've handled all steps of the authentication for it.
Fix should be simple: when an app's installed remotely from the browser, queue the installation and put up a notification asking the user to confirm the installation. Installation doesn't proceed until the user responds affirmatively to the prompt (if they respond negatively, the installation's de-queued). The authors are right, though, that the more tightly you integrate the browser-based services with the phone the less you can depend on the separation of the two for security. What's different here is that it's showing that tight integration between Google's services and the phone affects vendors other than Google.
That's strange, because the manufacturer says there are no firmware updates available for the SB6141 (or any of their other cable modems). It's possible to update the firmware of the router portion of their combined products, but that update doesn't touch the cable modem portion. Plus seeing as how the very first thing the cable modem will do after it establishes a connection to the head-end is check it's firmware image against the head-end and download and overwrite if they don't match...
Yes, there is. DOCSIS doesn't permit user updates of the modem's firmware, because that would allow users to bypass limitations set by the cable provider based on what service they've purchased. Only the cable head-end can download firmware to the modem, so the ISPs have to add the fix to their firmware images and deploy them to the modems. Yeah, I know, but the network design treats the modem as a part of the cable network and not as an end-user device like a router would be. Just remind yourself that the cable network ends at the Ethernet jack on the back of the modem, not at the coax outlet on the wall.
The developer themselves. It's already part of the process of transferring an app from one developer account to another. Google just has to modify the server portion to automatically change the identifier as part of the transfer process.
If the developer set up a separate Google account for their developer account and they're transferring everything, they can just transfer access and in theory Google would be oblivious. In practice however the transfer involves things like changing the merchant account to use the new owner's bank accounts and credit cards, granting access to new individual Google accounts and closing down the access by the previous owner, that kind of thing. Google's tech should be good enough to flag that kind of activity when they haven't been notified of the account changing hands and send an inquiry. One addition to the terms of service, saying that transferring the actual Google account without notifying Google is grounds for suspending the developer account and all apps associated with it until the matter's been resolved, and it becomes very much in the interest of the buyer to make sure the notification happened. Even something as simple as tying an organizational account to an "owner" account (eg. you can set up a separate Google account to link the developer account to, but your personal account gets listed as "owning" that separate account and retains permanent control over it) and treating any transfer of that link to a different account as a change of ownership would probably work 99% of the time. The buyer probably wouldn't go for the seller retaining total control and the ability to kick the buyer out at any time, and the seller probably doesn't want to lose their personal Gmail and other services tied to their personal account.
Thought: app stores need to change the app's identifying number when ownership changes hands. The app store can then notify users at the next update and let them choose whether to update and switch to the new version or reject the update. That'd put an end to this mess.
They can, however, unfortunately appeal the dismissal with prejudice, which is probably what they're doing. The appeal will probably result in a one-line rejection, but it delays the inevitable for them by another few weeks while the appeals court processes the paperwork.
Slashdot Mirror
I delegate creating passwords to PasswordSafe. The current standard policy is 15 characters, requires at least 2 lowercase letters, 1 uppercase letters, at least 1 symbol. The password database is backed up and available to my devices via a server I control. I've been steadily increasing the password length as hardware improves.
I can't believe that changing the client to use HTTPS URLs when checking for and downloading updates would disrupt the rest of the Web site that badly. And as far as users using HTTPS to browse the site, that shouldn't affect ads unless the ad networks are incapable of serving content via HTTPS. In this day and age, that should be an issue for only the most incompetent of ad networks.
I learned to code first in classes in high school (BASIC, FORTRAN, COBOL, Pascal) and then by reading the relevant books or documentation (C, C++, Lisp, Icon, Java, C#, Perl, Python, Ruby, PHP, Javascript et. al.).
The more interesting question is where developers first learned to program (a completely different skill from coding). IMO we don't need to teach children to code, we need to teach them to program. Which means first teaching them to approach problems logically and analytically, which is going to cause the loss of about 75% (my guesstimate) of the educational establishment when they can't deal with students who know how to analyze material, do independent research and call teachers on incorrect classroom material.
The liability isn't being created by user-posted content in this case. It stems from the site actually knowing about the actions of some users and failing to give notice when it could foresee that that failure would put other users at risk. It's the same principle that says that if I know of a danger on my property and fail to post notice of it or take steps to keep people out I'm liable if someone gets hurt by it. Section 230 never comes into play.
The big threat isn't that, it's a vulnerability in a server program on the zwave network that provides data from the devices that can be exploited to let you execute code on that device. Now you can load a program onto it that, rather than doing it's normal job, can connect to any of the PCs that can see that data. The PCs will see an internal connection which bypasses the router's firewall and quite possibly the PC's individual firewall if like most people you've told your PCs they're on a home network and can trust other local computers. Being able to do that only if you already have access to the inside of the house isn't particularly risky, the set of potential attackers is pretty limited. Being able to do that via WiFi, OTOH, means anybody driving by on the street could attack you and that's a whole 'nother order of risk.
Proper setup for IoT: wired networking (via powerline is probably the easiest), no WAN access. Vulnerabilities can still be exploited, but the attacker has to be inside your house to do it. A compromised PC could be used to stage an attack, but if they're compromised your PC they can control the devices directly if those are the targets and if the PC's the target they don't need to compromise the devices at that point.
For the wireless fans, I have bad news: there isn't any safe way to access IoT devices over WiFi. The connectivity-at-a-distance nature and lack of interface to configure encryption/authentication keys on the devices makes it inherently impossible.
There's a farm supply store near me that'd love a steady supply of the kind of high-quality bovine waste product Ms. Hurst is spewing...
I'd love to see IBM take a swing at this one, seeing as the original decision that allowed non-IBM PC-compatible machines to be created turned on the question of whether creating a BIOS that exposed the exact same interface as IBM's BIOS infringed on IBM's copyright if all other code could be proven to be entirely original. Under this decision the answer would be "Yes.", and IBM would be owed damages for every single PC created using a non-IBM BIOS that had any trace of the legacy BIOS API in it (at a minimum every BIOS that wasn't completely UEFI-only).
It might also be entertaining to analyze the effects of this ruling on Oracle's use of GPL- and LGPL-licensed glibc and kernel header files in their products that run on Linux. Neither license quite directly addresses the question of copying copyrighted API declarations into object files and executables. They address linking of various sorts, and copying into source code, but this particular aspect's deemed outside the scope of the license and thus not addressed.
It sounds like this method doesn't identify bugs, it identifies sections of code where the programmer was under stress. Those are likely candidates for sections of code where bugs can occur, but the developer likely already knew that. It doesn't help at all in figuring out exactly what errors there are in that stretch of code, and it won't help in deciding where to test because you should already be testing all the code. If you aren't, you've got bigger problems than merely bugs in the code and you likely won't be taking advantage of this technique either. Basically, it's yet another management idea that sounds good but doesn't fix the actual problem.
Better yet, use a password which gives more combinations than a PIN code. As for storing information, Android does include that functionality in the form of device encryption. You have to enable it, but it's certainly there. Communication... S/MIME encryption should already be supported by the email app and doesn't require any intermediate servers to know your key.
For real-time chat 3rd-party apps are the only solution. I'm still looking for one based around x.509/SSL certificates, though. I don't trust home-baked encryption and none of the apps out there seem to want to discuss the details of what's underneath their promises.
He probably shouldn't be allowed to sue for that much, but then large rightsholders shouldn't be allowed to sue for the ridiculous amounts they sue for either. No matter, whether he should be allowed to or not, the law says that's what he can sue for since they infringed on his copyrights. Those are the rules the big corporations and rightsholders made, I don't see any reason why this photographer shouldn't play by them.
The original set of emojis worked nicely for incorporating emotional and attitude markers into otherwise emotionless text. I think we do need something like that in Unicode. The current set, though, goes way too far beyond that and needs to be mercilessly pruned back. Unicode is not supposed to be a way to incorporate every single image anyone could want as a single character. Trim it back and use images for images. To quote someone, "If you're trying to design a hammer that can turn screws, it's time for you to put the hammer down and go get a screwdriver.". OK, it's not an exact quote, but I can't do justice to the interspersed expletives in the original.
I've experienced the bias against older tech workers. I've also seen the results of that bias: work that would've gotten a failing grade even in the college courses I took, let alone at some of my employers. There's a considerable advantage to having been there, done that, can see how current problems match previously encountered problems and what methods already exist to solve them. To give an extreme example, traditional Web applications (most logic on the server, Javascript in the client is used primarily for input validation and display formatting) mirror very closely the flow of ancient 3270 workstation "green-screen" applications: the server sends a block of display and validation instructions to the client, the user enters the data without interacting with the server, the client sends the completed form back to the server as a single block for processing. The same flow held for the forms applications I build for DEC VAX/VMS in the 80s. And many of the tricks developed to maintain session data across requests for web application are the same tricks we used for the same purpose way back when. I can see the same pendulum swing at work as well: 3270 workstations gave way to interactive terminals (where the application could directly interact with the user), which gave way to forms applications, which gave way to thick clients (PC applications that accessed remote servers via various protocols), which in turn gave way to Web applications, which are now giving way to thick clients again (this time Javascript framework applications running in the browser accessing remote servers via XML/JSON and RESTful interfaces). That perspective gives me a big advantage in knowing where to go for things that already exist and have had all the kinks thoroughly worked out that I can apply to the current problem, rather than having to work solutions out from first principles or copy-and-paste code from StackOverflow as a black box as many of the younger developers do.
Most of the bias I attribute to a mistaken belief that "old" = "unable/unwilling to learn". Some of that belief probably comes as a reaction to the normal skepticism older people have to the latest "silver bullet" sales hype. We've seen those fail to live up to the hype time and time again, someone who's only been in the business 5 years and who hasn't maintained a single application through many update cycles hasn't gotten the first-hand experience with the fallout. It's not that the shiny new tech isn't good, but the salesman is probably over-promising to try and seal the deal and I'd prefer to find the gotchas in a test project rather than by having production fall over.
For AR I don't expect the phone to be the display. As I said, something like Google Glass which uses the phone as the processing and communications unit and simply displays on effectively your entire field of view. No need to bind the phone permanently to the display, because displays will improve (just like right now we don't bind the phone permanently to a headset, we connect them via Bluetooth and we can replace the headset with a better model without needing to replace the phone in the process).
The whole idea that people are inherently lazy and won't work without being forced to always puzzled me. Most of the people I know want to do something productive, but more often than not it's either not something they can get enough income from quickly enough to be able to drop their day job and start doing it full-time or it's not something they can get enough income from to keep the bills paid. Give them a guaranteed basic income and they won't sit around doing nothing, they'll start doing what they want to do (instead of the day job they have to have because it pays the bills).
And on the flip side, what does Donald Trump do exactly? I know he's rich and considered successful, but what work does he actually do? Or Kim Kardashian? It always seemed to me that the more successful you were, the more well-off you were, the less actual work you appeared to do each day. I know there's research involved in say running a major investment fund like Warren Buffet does, but he doesn't do the majority of it. 95% is delegated out to subordinates who do the legwork and write up the analyst reports, Buffet himself just goes over those reports and makes the final decisions. It's something only he can do, but he's not spending 40 hours a week nailed down to a desk poring over corporate reports and newspaper articles and stock trade data, running spreadsheet calculations to figure out what's behind the stock movements and what's likely to happen in the future.
To quote a mill supervisor, "I don't want the industrious guy who'll clean up the mess with a smile. I want the lazy bastard who'll figure out how to stop the mess from happening so he doesn't have to clean it up all the time.".
I don't think we've hit peak smartphone, but we're at a plateau. The next steps will be three things:
1. Reduced cost and improved durability, bringing smartphones to those areas of the world that currently can't afford them.
2. Improved battery life. That's going to come from battery tech, not the phone side.
3. Augmented reality. Not virtual reality, but something like Google Glass that can use the entire surface of the lens as a display instead of just a small chunk in a corner.
There are inserts that fit the Keurigs that you can fill with your own ground coffee, then empty after it's brewed. I'd love to use them, it'd give me a wider variety of coffees. The only problem is that none of them seal properly, water and grounds come out the top and make a mess and the leakage interferes with the brewing. If Keurig really wanted to solve the problem, put the research into modifying the MyK-Cup so it seals properly and the water flows through the grounds rather than off the top and through the open mesh screen.
If they have access to the PC, all they have to do is wait for the user to log in to Google themselves, then use that session for their purposes. No need at all to wait for an unattended browser.
The idea is that it won't matter whether you have 2FA turned on or not, you've already authenticated to your Google account and your compromised browser can then use it's access to that account to push the malicious app to your phone and activate it. 2FA can't protect you from that because the malicious code starts after you've handled all steps of the authentication for it.
Fix should be simple: when an app's installed remotely from the browser, queue the installation and put up a notification asking the user to confirm the installation. Installation doesn't proceed until the user responds affirmatively to the prompt (if they respond negatively, the installation's de-queued). The authors are right, though, that the more tightly you integrate the browser-based services with the phone the less you can depend on the separation of the two for security. What's different here is that it's showing that tight integration between Google's services and the phone affects vendors other than Google.
That's strange, because the manufacturer says there are no firmware updates available for the SB6141 (or any of their other cable modems). It's possible to update the firmware of the router portion of their combined products, but that update doesn't touch the cable modem portion. Plus seeing as how the very first thing the cable modem will do after it establishes a connection to the head-end is check it's firmware image against the head-end and download and overwrite if they don't match...
Yes, there is. DOCSIS doesn't permit user updates of the modem's firmware, because that would allow users to bypass limitations set by the cable provider based on what service they've purchased. Only the cable head-end can download firmware to the modem, so the ISPs have to add the fix to their firmware images and deploy them to the modems. Yeah, I know, but the network design treats the modem as a part of the cable network and not as an end-user device like a router would be. Just remind yourself that the cable network ends at the Ethernet jack on the back of the modem, not at the coax outlet on the wall.
The developer themselves. It's already part of the process of transferring an app from one developer account to another. Google just has to modify the server portion to automatically change the identifier as part of the transfer process.
If the developer set up a separate Google account for their developer account and they're transferring everything, they can just transfer access and in theory Google would be oblivious. In practice however the transfer involves things like changing the merchant account to use the new owner's bank accounts and credit cards, granting access to new individual Google accounts and closing down the access by the previous owner, that kind of thing. Google's tech should be good enough to flag that kind of activity when they haven't been notified of the account changing hands and send an inquiry. One addition to the terms of service, saying that transferring the actual Google account without notifying Google is grounds for suspending the developer account and all apps associated with it until the matter's been resolved, and it becomes very much in the interest of the buyer to make sure the notification happened. Even something as simple as tying an organizational account to an "owner" account (eg. you can set up a separate Google account to link the developer account to, but your personal account gets listed as "owning" that separate account and retains permanent control over it) and treating any transfer of that link to a different account as a change of ownership would probably work 99% of the time. The buyer probably wouldn't go for the seller retaining total control and the ability to kick the buyer out at any time, and the seller probably doesn't want to lose their personal Gmail and other services tied to their personal account.
Thought: app stores need to change the app's identifying number when ownership changes hands. The app store can then notify users at the next update and let them choose whether to update and switch to the new version or reject the update. That'd put an end to this mess.
They can, however, unfortunately appeal the dismissal with prejudice, which is probably what they're doing. The appeal will probably result in a one-line rejection, but it delays the inevitable for them by another few weeks while the appeals court processes the paperwork.