Foreign election interference has gone both ways, on several axes. The USA has certainly intervened in many foreign elections, as they have in ours, since the founding of the USA. Public statements of concern about or support for one candidate or another have been traditional, at many levels of public and private announcement. So has foreign support of election monitoring, to help ensure a fair election, both by the US and on several occasions of USA elections.
A CS degree helped employability for _military_ work in that period. The money for leading edge research involved military work, such as guidance systems and cryptography.
That old webcomic covered a surprising number of very real user interface issues. It also covered office politics, and technological egotism, and interactions between complete geeks and other people. It's still surprisingly apt after being in reprints for years.
> So if almost 60% approve, isn't that about as much consensus as you ever get on a standard?
I I may say so, no. Lack of consensus for standards bodies is very real problem, and discourages people from following _other_, more critical standards set by that same group. Consensus for a standards group is usually _much_ higher. There have been notable exceptions, such as the OOXML standards approved by the IEEE. The shameful abuse of the approval process for that standard has been well publicized. I suspect, from conversations with various DRM publishing companies, that this process was burdened by similar abuse.
If you find a title for this, please point it out. As one of "the guys who cut their teeth in the 80s and 90s and then got old", a mecha suit instead of retirement sounds wonderful.
The discussion is interesting, but _please_ stop mixing open source with free software. They have different goals, different history, and different licensing. FOSS is not one license, or one model of development. The largest split is between "free software" and "open source software".
If I may suggest a better model, please review the "tragedy of the commons" and approaches used to prevent it. Companies and individuals have started from "free to use" software, such as BSD UNIX and the openly published parts of a great number of projects in CPAN, in Maven and Ant and Gradle repositories, and in the modern pypi.org repository, Many people refuse to share their modifications, their "secret sauce", even with the clients who paid for the work or who are given the resulting binaries for C, C++, or Java. It also applies to back end software sold as a service. The result is that the "secret sauce" gets splintered and becomes very difficult to support, to integrate for publicly available source code. It also becomes very difficult to assess for performance issues, for security vulnerabilities, and for _software patent violations_.
The difficulties have been notable on numerous occasions. Tivo's attempt to patent their software and work their way around the GPL is now infamous. I've worked with five major projects in the last decade where a vendor took their codebaase private from an open source project and destabilized it by migrating the project away from the community standards in their own proprietary fork, which within a few years _did not work properly_ anymore. The pain and expense of detangling it from the proprietized source code to activate desired new features was quite large, and paid for considerable chunks of my salary at the time.
Individual users, or companies, consider their proprietary code so important, and the risk to their personal projects, so large that they refuse to use the very carefully thought out and clear GPL licenses. The then endanger others who may accidentally copy parts of their software, or reverse engineer it without intent, or who may copy software which was not clearly distinguished and labeled as GPL. They put others at risk, and companies who collaborate or who privately share code with them may put _them_ at risk because the licenses are much more restrictive, confusing, or even dangerous.
I've been a major advocate in my workplace of using genuinely free software, with a GPL wherever possible, precisely so that competitors cannot proprietize work that we publish. I've encountered workplaces where various open source licenses were used for proprietized software which became unsupportable, precisely because the proprietized components became incompatible with the upstream over time and because they lacked the userbase to do thorough debugging and quality control of internal modifications. From experience, I consider _that_ poison.
I've encountered personnel who've considered the GPL poison. I've encountered far more projects where the proprietary extensions became deadly and unusable, and ruined the original project's development.
> Perimeter defense as a defense in depth strategy is fine. In theory. In practice, it breeds an assumption that the network is "safe" in some important sense.
"Safer" is the operative word. A VPN is typically associated with a firewall that restricts access to certain systems or certain portions of a network through a gatekeeper. This often includes components that are relatively difficult to activate a full-blown "single sign-on" method on, or services that are far more difficult to secure individually. These may include personal laptops and IoT devices, which are notoriously difficult to secure individually or internally exposed services which may have zero-day exploits, such as the firewalls themselves. Even exposed laptops can, and will, suffer constant attack from outside if the firewall doesn't efficiently block them. Tools such as a VPN allow reducing the exposure of such components to the world at large profoundly, while still allowing offsite access when needed.
Part of the point of the firewall, and the VPN to authorize access through it, is that there is no reason to expose the entire internal network to every source of probes in the entire Internet. If the team you work with has successfully activated a good single-sign-on configuration, then the VPN can usually provide just that same convenience. And I'm sad to say, even Macs and Linux systems have had remote access exploits that need much more than an enforced signle-sign-on technology to protect from.
>> For most environments, it's added overhead that returns nothing concrete for ordinay use, and for which VPN is a much simpler and much lower cost system to implement.
> Also wrong, particularly if you also end up implementing a single sign-on system in addition to the VPN.
Single sign-on, done well, reduces the pain of a VPN as well as other tools. But please do not replace one layer of security (of firewalls and VPNs) with another layer (of single sign) and say that the other has no use. Also: have you, personally, ever tried to activate and enforce a single-sign-on technology across a whole company? I have, many times in my career. It's also not cheap or a trivial task.
Until your endpoint is hacked with a zero day exploits. Also sadly, too many websites engage in profound tracking efforts involving tracking cookies, back end shared databases, and commonly sourced websites carrying personal information to be completely sure of privacy.
> The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems.
If I may disagree? It's based on the notion that it's possible to reduce your vulnerability, profoundly, by reducing your exposed surface and enabling some tracking of who is accessing the internal network with what privileges. I'm afraid there is not complete security. Locking casual access outside the local network is never absolutely effective, but it can profoundly help in keeping casual access to internal resources _moderately_ proscribed. And it does so in a method that employers, and most developers, can deal with in a comprehensible way.
> [Google's approach ] It's a better approach than VPNs. More secure, more convenient, more flexible.
It is _expensive_, in manpower to maintain the sophisticated systems in and in detailed management of the various resources. Google has internal engineers who delight in solving such technology sensitive and resource demanding issues. For most environments, it's added overhead that returns nothing concrete for ordinay use, and for which VPN is a much simpler and much lower cost system to implement.
_Excellent_ for you and your crew. I do wonder if you'll feel quite the same way in several decades, when you realize a senior engineer was born _after_ you started in the field. It's a strange experience, one I can attest to personally.
I've been very fortunate to work with mentors, and to mentor, people of various ages in my decades in technology. There are many valid reasons for age bias: the generally better medical condition of younger workers is one of them. Knowledge of the latest technologies, and excitement rather than hard-won cynicism about them, can lead to exciting development in leading edge fields. Conversely, hard-learned caution about promises of incredible improvements, or knowledge of the the failures of the last attempt, can speed development and prevent catastrophic losses. The "best practices" learned over decades of productive work can be invaluable, even company saving or life saving.
One of the most difficult problems I've had with younger colleagues is that we train them, and they _leave_. We don't necessarily have enough work in our team for another senior expert, even if we helped create them. We've had good success cross-pollinating with partners and clients, hiring from each other's teams people who'd be better suited for an ongoing role with the other group.
These employment shifts are not always a promotion. There have been people who got in over their heads, and needed to downgrade to a more limited role to _do_ good work and stay employed. There have also been lifestyle choices as people needed stable money or a stable home life for family, or had medical needs, and those were demotions in some cases. Those also worked out better when they switched company.
I'm old enough, myself, to see the point in my mental capacity to produce _new_ tools efficiently.
>...bringing about the GPL-poison effect no less.......(and if that wasn't enough) against an organization based in China?????
Since they sell the devices in the USA, there would seem to be grounds to bring them to court in the USA if they were violating the GPL.
And If I may say so, it seems disingenuous to refer to the GPL as a "poison effect". A client recently gave me an excellent simile for it. GPL poisoning your work is like vaccines causing autism. It's a fear that made sense in a scholarly analysis at one time, and which many alarmed people took to hear. But that unjustified fear has lead to people dangerously isolating their own work and poisoning _other_ work,
Fortunately, the current maintainers have already published their source on github.com.
NAT is a _layer_ of protection. What I may want, what I can support, and what a non-technical person can afford or manage in their home network are different constraints for any security situation. Saying "you want a firewall" does not mean "NAT does not help", especially by reducing the easily scanned and exposed network space.
What would you define as "no direct Internet link" ? Unable to reach out to the Internet? Or unable to reach directly to the device from outside? NAT buys you "no direct access from outside", barring someone breaking your cable modem security or your activating port forwarding. That's true even if you set DHCP reservations for devices on your internal network. It's even possible to set up a firewall _behind_ your cable modem to block additional traffic.
> My coworkers and I were joking around this week that we had absolutely no work do before the next data drop.
This is just the sort of thing my colleagues and I avoid, and try to help companies we work with avoid. There should _always_ be a stack of useful projects available for just such lag periods, to keep people engaged and to do work that didn't fit into the priority meeting. Whether it's evaluating the next software upgrades, training people on software they need everyday, or clearing away obsolete hardware and software before it fails during deployment. If there is not enough such work available to fill in the gap time, you're overstaffed and should look for another department that needs you more or prepare your resume.
If nothing else, _cross-train_. And be aware the sharpest, most aggressive of you may migrate to a better paying role or get shoved up to management, so help them move on and get ready to take their place as the senior engineer.
> YOU ARE CULPABLE! You are at fault, it is YOUR PROBLEM, that is the end of it
Establishing enough culpability, in a court of law, with the End User License Agreement for most such devices is not feasible. And by the time such a lawsuit makes it to a courtroom, the original vendor is usually gone. It's an extremely volatile field, these vendors are not thinking in the long term and so far only a few have lasted even 3 years.
It's a _start_, and an extremely useful one. There is a goal of some IPv6 and IoT advocates that every device in the world should be accessible via publishable IPv6 address. It was also one of the underlying constraints in setting the size of the IPv6 address space. Such exposure to externally routable or scannable addresses is completely unnecessary for most "IoT" devices, which can be run more safely in a "the device polls specific services on the Internet" rather than a "anything on the Internet can reach to and poll them" configuration.
If your entire internal network has externally routable IP addresses, then why did you spend any effort whatsoever enabling them with external addresess? Or spend the time and energy maintaining a firewall to protect them? Worse, from some personal and professional experience, why even leave the _option_ on your firewall to "open it up and try to debug things with the firewall open". I'm sad to say that I've seen some experienced and well paid professionals do just that, simply opening up the whole firewall and trying to resecure it after the immediate filtering issue was relieved.
Just please, don't mistake it for "completely secure communications" because one portion of the data flow is protected. This is _China_ publishing it. They have a strong history of insisting on control of communications at several stages.
> No, that misses the point entirely. It's not that it's too easy to connect devices to the Internet, but rather that, at least sometimes, it is very difficult, if not nearly impossible, to prevent devices from connecting to the Internet.
I can attest to this from personal and painful experience with such devices as printers and certain medical appliance toolkits for "doctor's office" use.
> It's largely not the individuals purchasing the insecure IoT devices who are directly harmed by the security holes.
I agree that most of the harm is indirect. Botnets hosted on various IoT devices are an issue. Another issue is the regulatory difficulty of embedding robust security in such devices. To quote from the Wikipedia article on encryption export controls:
> As of 2009, non-military cryptography exports from the U.S. are controlled by the Department of Commerce's Bureau of Industry and Security.[9] Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. Militarized encryption equipment, TEMPEST-approved electronics,
For many low end device vendors, which are the bulk of IoT manufacturers, it is simply _not worth_ the effort of talking with the Department of Commerce. So I'm afraid it's an often neglected feature to encrypt or sucre the data on the device, in transit, or on the remote servers which may collect and organize such data for the customers and for the vendor.
Slashdot Mirror
Foreign election interference has gone both ways, on several axes. The USA has certainly intervened in many foreign elections, as they have in ours, since the founding of the USA. Public statements of concern about or support for one candidate or another have been traditional, at many levels of public and private announcement. So has foreign support of election monitoring, to help ensure a fair election, both by the US and on several occasions of USA elections.
A CS degree helped employability for _military_ work in that period. The money for leading edge research involved military work, such as guidance systems and cryptography.
If I may disagree? A CS degree may be a poor return on investment, but it generally _has_ a measurable and positive return on investment.
That old webcomic covered a surprising number of very real user interface issues. It also covered office politics, and technological egotism, and interactions between complete geeks and other people. It's still surprisingly apt after being in reprints for years.
> So if almost 60% approve, isn't that about as much consensus as you ever get on a standard?
I I may say so, no. Lack of consensus for standards bodies is very real problem, and discourages people from following _other_, more critical standards set by that same group. Consensus for a standards group is usually _much_ higher. There have been notable exceptions, such as the OOXML standards approved by the IEEE. The shameful abuse of the approval process for that standard has been well publicized. I suspect, from conversations with various DRM publishing companies, that this process was burdened by similar abuse.
If you find a title for this, please point it out. As one of "the guys who cut their teeth in the 80s and 90s and then got old", a mecha suit instead of retirement sounds wonderful.
Many birds also eat bugs. Bats may be more effective, on an individual basis, but there are _many_ more birds in most ecosystems.
The discussion is interesting, but _please_ stop mixing open source with free software. They have different goals, different history, and different licensing. FOSS is not one license, or one model of development. The largest split is between "free software" and "open source software".
If I may suggest a better model, please review the "tragedy of the commons" and approaches used to prevent it. Companies and individuals have started from "free to use" software, such as BSD UNIX and the openly published parts of a great number of projects in CPAN, in Maven and Ant and Gradle repositories, and in the modern pypi.org repository, Many people refuse to share their modifications, their "secret sauce", even with the clients who paid for the work or who are given the resulting binaries for C, C++, or Java. It also applies to back end software sold as a service. The result is that the "secret sauce" gets splintered and becomes very difficult to support, to integrate for publicly available source code. It also becomes very difficult to assess for performance issues, for security vulnerabilities, and for _software patent violations_.
The difficulties have been notable on numerous occasions. Tivo's attempt to patent their software and work their way around the GPL is now infamous. I've worked with five major projects in the last decade where a vendor took their codebaase private from an open source project and destabilized it by migrating the project away from the community standards in their own proprietary fork, which within a few years _did not work properly_ anymore. The pain and expense of detangling it from the proprietized source code to activate desired new features was quite large, and paid for considerable chunks of my salary at the time.
I'll try to explain what I meant.
Individual users, or companies, consider their proprietary code so important, and the risk to their personal projects, so large that they refuse to use the very carefully thought out and clear GPL licenses. The then endanger others who may accidentally copy parts of their software, or reverse engineer it without intent, or who may copy software which was not clearly distinguished and labeled as GPL. They put others at risk, and companies who collaborate or who privately share code with them may put _them_ at risk because the licenses are much more restrictive, confusing, or even dangerous.
I've been a major advocate in my workplace of using genuinely free software, with a GPL wherever possible, precisely so that competitors cannot proprietize work that we publish. I've encountered workplaces where various open source licenses were used for proprietized software which became unsupportable, precisely because the proprietized components became incompatible with the upstream over time and because they lacked the userbase to do thorough debugging and quality control of internal modifications. From experience, I consider _that_ poison.
I've encountered personnel who've considered the GPL poison. I've encountered far more projects where the proprietary extensions became deadly and unusable, and ruined the original project's development.
> Perimeter defense as a defense in depth strategy is fine. In theory. In practice, it breeds an assumption that the network is "safe" in some important sense.
"Safer" is the operative word. A VPN is typically associated with a firewall that restricts access to certain systems or certain portions of a network through a gatekeeper. This often includes components that are relatively difficult to activate a full-blown "single sign-on" method on, or services that are far more difficult to secure individually. These may include personal laptops and IoT devices, which are notoriously difficult to secure individually or internally exposed services which may have zero-day exploits, such as the firewalls themselves. Even exposed laptops can, and will, suffer constant attack from outside if the firewall doesn't efficiently block them. Tools such as a VPN allow reducing the exposure of such components to the world at large profoundly, while still allowing offsite access when needed.
Part of the point of the firewall, and the VPN to authorize access through it, is that there is no reason to expose the entire internal network to every source of probes in the entire Internet. If the team you work with has successfully activated a good single-sign-on configuration, then the VPN can usually provide just that same convenience. And I'm sad to say, even Macs and Linux systems have had remote access exploits that need much more than an enforced signle-sign-on technology to protect from.
>> For most environments, it's added overhead that returns nothing concrete for ordinay use, and for which VPN is a much simpler and much lower cost system to implement.
> Also wrong, particularly if you also end up implementing a single sign-on system in addition to the VPN.
Single sign-on, done well, reduces the pain of a VPN as well as other tools. But please do not replace one layer of security (of firewalls and VPNs) with another layer (of single sign) and say that the other has no use. Also: have you, personally, ever tried to activate and enforce a single-sign-on technology across a whole company? I have, many times in my career. It's also not cheap or a trivial task.
It seems like a direct violation of several articles in the EU charter. So I think that "illegality" is not too strong a word.
Until your endpoint is hacked with a zero day exploits. Also sadly, too many websites engage in profound tracking efforts involving tracking cookies, back end shared databases, and commonly sourced websites carrying personal information to be completely sure of privacy.
> The perimeter defense model is based on the notion that it's possible to build a network that is physically secure and which contains only trusted, managed systems.
If I may disagree? It's based on the notion that it's possible to reduce your vulnerability, profoundly, by reducing your exposed surface and enabling some tracking of who is accessing the internal network with what privileges. I'm afraid there is not complete security. Locking casual access outside the local network is never absolutely effective, but it can profoundly help in keeping casual access to internal resources _moderately_ proscribed. And it does so in a method that employers, and most developers, can deal with in a comprehensible way.
> [Google's approach ] It's a better approach than VPNs. More secure, more convenient, more flexible.
It is _expensive_, in manpower to maintain the sophisticated systems in and in detailed management of the various resources. Google has internal engineers who delight in solving such technology sensitive and resource demanding issues. For most environments, it's added overhead that returns nothing concrete for ordinay use, and for which VPN is a much simpler and much lower cost system to implement.
> Not true, the average age at Google has increased a lot.
So has the role of those people. They're building on, or maintaining, an existing technology.
_Excellent_ for you and your crew. I do wonder if you'll feel quite the same way in several decades, when you realize a senior engineer was born _after_ you started in the field. It's a strange experience, one I can attest to personally.
I've been very fortunate to work with mentors, and to mentor, people of various ages in my decades in technology. There are many valid reasons for age bias: the generally better medical condition of younger workers is one of them. Knowledge of the latest technologies, and excitement rather than hard-won cynicism about them, can lead to exciting development in leading edge fields. Conversely, hard-learned caution about promises of incredible improvements, or knowledge of the the failures of the last attempt, can speed development and prevent catastrophic losses. The "best practices" learned over decades of productive work can be invaluable, even company saving or life saving.
One of the most difficult problems I've had with younger colleagues is that we train them, and they _leave_. We don't necessarily have enough work in our team for another senior expert, even if we helped create them. We've had good success cross-pollinating with partners and clients, hiring from each other's teams people who'd be better suited for an ongoing role with the other group.
These employment shifts are not always a promotion. There have been people who got in over their heads, and needed to downgrade to a more limited role to _do_ good work and stay employed. There have also been lifestyle choices as people needed stable money or a stable home life for family, or had medical needs, and those were demotions in some cases. Those also worked out better when they switched company.
I'm old enough, myself, to see the point in my mental capacity to produce _new_ tools efficiently.
> ...bringing about the GPL-poison effect no less.... ...(and if that wasn't enough) against an organization based in China?????
Since they sell the devices in the USA, there would seem to be grounds to bring them to court in the USA if they were violating the GPL.
And If I may say so, it seems disingenuous to refer to the GPL as a "poison effect". A client recently gave me an excellent simile for it. GPL poisoning your work is like vaccines causing autism. It's a fear that made sense in a scholarly analysis at one time, and which many alarmed people took to hear. But that unjustified fear has lead to people dangerously isolating their own work and poisoning _other_ work,
Fortunately, the current maintainers have already published their source on github.com.
NAT is a _layer_ of protection. What I may want, what I can support, and what a non-technical person can afford or manage in their home network are different constraints for any security situation. Saying "you want a firewall" does not mean "NAT does not help", especially by reducing the easily scanned and exposed network space.
What would you define as "no direct Internet link" ? Unable to reach out to the Internet? Or unable to reach directly to the device from outside? NAT buys you "no direct access from outside", barring someone breaking your cable modem security or your activating port forwarding. That's true even if you set DHCP reservations for devices on your internal network. It's even possible to set up a firewall _behind_ your cable modem to block additional traffic.
> My coworkers and I were joking around this week that we had absolutely no work do before the next data drop.
This is just the sort of thing my colleagues and I avoid, and try to help companies we work with avoid. There should _always_ be a stack of useful projects available for just such lag periods, to keep people engaged and to do work that didn't fit into the priority meeting. Whether it's evaluating the next software upgrades, training people on software they need everyday, or clearing away obsolete hardware and software before it fails during deployment. If there is not enough such work available to fill in the gap time, you're overstaffed and should look for another department that needs you more or prepare your resume.
If nothing else, _cross-train_. And be aware the sharpest, most aggressive of you may migrate to a better paying role or get shoved up to management, so help them move on and get ready to take their place as the senior engineer.
> Visual Studio is free bro.
The lessons it teaches are not: they can cost years of employment and thousands of hours of painful labor to unlearn destructive lessons.
> YOU ARE CULPABLE! You are at fault, it is YOUR PROBLEM, that is the end of it
Establishing enough culpability, in a court of law, with the End User License Agreement for most such devices is not feasible. And by the time such a lawsuit makes it to a courtroom, the original vendor is usually gone. It's an extremely volatile field, these vendors are not thinking in the long term and so far only a few have lasted even 3 years.
It's a _start_, and an extremely useful one. There is a goal of some IPv6 and IoT advocates that every device in the world should be accessible via publishable IPv6 address. It was also one of the underlying constraints in setting the size of the IPv6 address space. Such exposure to externally routable or scannable addresses is completely unnecessary for most "IoT" devices, which can be run more safely in a "the device polls specific services on the Internet" rather than a "anything on the Internet can reach to and poll them" configuration.
If your entire internal network has externally routable IP addresses, then why did you spend any effort whatsoever enabling them with external addresess? Or spend the time and energy maintaining a firewall to protect them? Worse, from some personal and professional experience, why even leave the _option_ on your firewall to "open it up and try to debug things with the firewall open". I'm sad to say that I've seen some experienced and well paid professionals do just that, simply opening up the whole firewall and trying to resecure it after the immediate filtering issue was relieved.
Just please, don't mistake it for "completely secure communications" because one portion of the data flow is protected. This is _China_ publishing it. They have a strong history of insisting on control of communications at several stages.
> No, that misses the point entirely. It's not that it's too easy to connect devices to the Internet, but rather that, at least sometimes, it is very difficult, if not nearly impossible, to prevent devices from connecting to the Internet.
I can attest to this from personal and painful experience with such devices as printers and certain medical appliance toolkits for "doctor's office" use.
> It's largely not the individuals purchasing the insecure IoT devices who are directly harmed by the security holes.
I agree that most of the harm is indirect. Botnets hosted on various IoT devices are an issue. Another issue is the regulatory difficulty of embedding robust security in such devices. To quote from the Wikipedia article on encryption export controls:
> As of 2009, non-military cryptography exports from the U.S. are controlled by the Department of Commerce's Bureau of Industry and Security.[9] Some restrictions still exist, even for mass market products, particularly with regard to export to "rogue states" and terrorist organizations. Militarized encryption equipment, TEMPEST-approved electronics,
For many low end device vendors, which are the bulk of IoT manufacturers, it is simply _not worth_ the effort of talking with the Department of Commerce. So I'm afraid it's an often neglected feature to encrypt or sucre the data on the device, in transit, or on the remote servers which may collect and organize such data for the customers and for the vendor.