That depends. Security against what type of threat?
Perhaps. The jury is still out on that front, and it will be at least 6+ months, before it can be known for sure.
Windows 7 has improved defaults, such as the requirement for users to 'elevate' to perform Administrative functions.
Helps protect against unintentionally running a program.
Reducing the number of users who will accidentally run malicious code, and UAC is an improvement, but not a robust security improvement really -- the user education in UAC has not gone far enough.
When the threat is misguided, misinformed, or conned users, UAC is a pretty feeble improvement.
Also, I am not sure that "Making it harder for users to run as Administrator", and imposing it by default counts as a better security.
You could do this even in XP, in an IT environment, don't give users Administrator rights to their own workstations, setup suitable NTFS file permissions.
Do user interface changes to reduce user mistakes count as security improvements?
No, they count as better education for humans.
Still, on the vulnerability front, the attack surface is still as large as before, and there are many reasons to suggest a large number of vulnerabilities will eventually be discovered in this behemoth OS, just as they were found in XP.
I believe we can expect more in the same vein as the SMB v2.0 MS09-050 vulnerability, in the near future, and more local user privilege escalation holes as well.
How do you define "unusual/anomalous" traffic ? Like when I host an online shop, and I get a lot of traffic on the 9494 (no, it's not that port, only an example) port where I keep my jsonrpc server ?
No.. but if you had never generated any 9494 traffic before, and suddenly generate a huge volume of it to a bunch of Korean IP addresses (from a US-based server), that might be considered a bit suspicious.
I would guess, in most cases, the ISP would probably ignore port 9494 traffic, unless, say it was udp 9494 at a 500,000 packets per second rate..
No... that's not an issue the operators need be concerned with. The government can listen in regardless, through FISA, CALEA, Patriot Act, Lawful Interception technologies on the carrier's networks.
I wish I could elaborate further on the matter, but that's a dangerous proposition.
One reason to stick with simpler encryption technology, is it's a cheaper, commodity part.
New algorithms take time to develop: R and D costs, mean more expensive products, not to mention the requirement to replace expensive network infrastructure in order to adopt new standards.
I'm more concerned about compromise of the user authentication process.
In the worst case it could result in the ability of an eavesdropper to capture your subscriber ID, and make international roaming calls as you, so they avoid racking up expensive charges themselves.
Plotting traffic, and destinations, in the aggregate is standard practice, get over it.
Ever hear of IPFIX, Netflow?
If you send 100 gigs a day over port 25, to umpteen thousand destinations, you bet your ISP should consider looking into that, if the traffic is unusual/anomolous.
Looking at specific packets, or capturing sessions, I think is unlikely for ISPs to do in most cases, unless nefarious activity is already strongly suspected in those packets.
It's not realistic due to the amount of bits most ISPs transferred, they would need massive storage capacity to hold even a few hours of traffic.
The only way I think ISPs ever do take detailed looks into your packets, or some connections' packets is using automated tools: deep packet inspection, primarily, to detect and throttle Peer to Peer traffic (such as BitTorrent).
It is conceivable that some day, someone might make a "Botnet CnC detector" appliance, however.
Don't hold your breath.
[Although I am still hopeful],
It has not been demonstrated (yet) that any version of Windows ever developed or that will ever be developed has robust security.
If you see a lamp on the ground and the couch burning through your neighbor's front window, is there a problem with you opening the front door, and dragging a bucket in, to douse the flames?
Yeah, I guess they could have you thrown in jail for barging in like that, and getting some water on their rug....
It's not that hard... there are free encryption libraries, many cheap authenticators, stream ciphers, e.g. Poly1305-AES, Salsa20/8, Curve25519, Rabbit, Blowfish, for actual data.
No need to use AES-768 here.
Actually, message encryption isn't required to protect against command hijacking, only digital signing and public key authentication (using a MAC) which is extremely cheap, and easy to do, thanks to open source OpenSSL and also, crypto libraries built into Windows.
server digitally signs a MAC / message hash with DSA, client authenticates only the hash, then validates the message matches the hash.
I think the only reason botnet operators aren't widely using message authentication, is they know, security researchers rarely go on the offensive, there might be legal issues with tampering with their code, AND:
There's no point in trying to defeat security researchers, with digital signatures.
Security researchers are essentially hackers themselves -- bringing in bloat like cipher code makes it probable the security researchers can find a buffer overflow, or other exploitable element in the botnet code itself, thus the bloat involved to digitally sign things becomes self-defeating.
The lack of a treaty does not, but the law of that country might.
Also, even if an extradition arrangement is in place, it doesn't mean it will happen.
Many countries are unlikely to spend precious law enforcement resources to attempt to apprehend someone for anything short of a major crime.
In addition, they are not likely to do it unless the act is illegal in their own country, not a political crime, and the country they extradite to will respect the basic human rights of the prisoner (such as right to life)
Also, you can't extradite someone from another country, when you don't know which country they are living in, and they have gone to lengths to "blend in" and do nothing conspicuous.
Sure they might be in an extraditable country, but there are hundreds of countries in the world..
It's a small planet, but there are lots of places to hide.
Git is a big mess in some ways (though still way better than using CVS), it's not better than Bazaar, too many commands, too many options, crappy windows support; Silly need for repository maintenance, ala git-gc; incomplete, unclear documentation. You can very easily shoot yourself in the foot with git, and accidentally destroy important history info (eg git-push --force), more so than any other version control system.
Mercurial is a lot closer to CVS/SVN in terminology, much easier for developers to adapt to. VCS should be simple, and it's really rather snappy.
Personally, I would say Bazaar is a fine choice for Emacs... if they should decide they need to change, they should switch to Mercurial and avoid Git like the plague it is:)
Never get deeply into either, operator overloading just obfusticates function calls, and in C++ is simply a twee excuse for not making strings a first class type, huge design error in C++, every idiot I see is writing a new string package, since it took years(decades) to get StdLib standardised
Overloading has useful applications for custom datatypes that have nothing to do with strings.
I would agree beginners have no business worrying about it though. It's more like a thing you use if you are developing libraries for use by other programmers.
Examples: arbitrary precision math libraries, arbitrary length 'bitvector' classes.
I'm sorry you feel it inadequate about C++ not having a native string type, but this is by design.
C/C++ is widely deployed, and standardization for new versions takes a long time, as industry players get to duke it out.
Rolling your own string class or 'string wrapper' in C++ is very doable, sensible, and a better choice than using standard string, usually, as the StdLib string classes are fairly limited, have issues, and won't provide you with certain niceties, such as proper Unicode support.
It's just a fact that C++ standard classes are feeble, and you need to do something like this for almost every program (unless you re-use your same custom String class for every one, or use one provided by your standard framework such as QString (QT), which is recommended).
And the STL (Standard Template Library) is an even bigger embarrasment.
In addition, no pattern matching, case-insensitive search operations, no equivalent to Java String class options such as equalsIgnoreCase, regionMatches, etc.
You can't do a basic case-insensitive compare with a straight-forward method name in C++.
The C++ string class is pretty much a feeble datatype with limited capabilities, and useless for real-world applications: it deserves to be re-invented, frequently.
I'd be surprised to see some programmer get along with just 'string' and no use of the c_str() method, or [] element accesses, for quick and dirty comparisons, using standard C functions, or using STL-inspired hacks and iterators on their string class.
Don't dare try to bring <algorithm> or <functor> into this.
That's also a bad answer that C++ STL adds.
Needing to get at individual character elements to do such simple things as case-insensitive comparison, matching, search, OR common transformations (turn a string into all uppercase), is a very bad answer, C++ StdLib string class sucks: in fact, it makes C's StdLib string functions look supreme by comparison.
A little new simple code that might need to be debugged, is better than complex code bringing template specializations and elaborate STL algorithms, custom loops, too.
I'd rather debug a custom string class with a few added methods for case-insensitive compares, then compare thousands of places throughout code, where a standard string class was used with a tight loop, eg
The problem with BASIC is it is not structured programming, and the syntax is a mess.
And GOTO is an integral statement in any attempt to implement a computer algorithm in BASIC, which is the bane of structured programmers.
Using English words for certain things as in VB is reminiscent of COBOL, the syntax is more complicated than other programming languages, and the control structures are abysmal and difficult for a beginner to use.
Real programming, even at the novice level, uses structured languages. Which, by the way, is a lot more elegant, structurally simple, logically simpler, and easier for a beginner to deal with than BASIC.
Many beginners interested in computers, give up programming altogether, after being exposed to the horror that is BASIC.
It's fine that some folks make a good living playing with VB.
I'm saying that VB is more complicated, and is more suitable for advanced programmers.
The language is not suited for teaching beginners.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
PASCAL.. mediocre choice.
C, okay... C++.. if you insist.
Well, some portion of the people who want to illegally migrate across the border, may already be able to cross legally..
But not with the drugs or other contraband they want to smuggle across.
Smuggling rings like this, may very well be able to afford high-tech gear, as it is.
(I suppose) it just depends on what their profits have been in the past, and to what length they will go through.
I suspect radar, infra-red camouflage, and all sorts of fancy gear are not out of the question, as long as they can get access to it while in the US.
Um... many areas of the border are indeed Desert or near-Desert, but that doesn't mean no vegetation or trees. There are several areas near the border where there might be significant vegetation to conceal immigrants..
portions have been cleared, but that doesn't necessarily mean an immigrant won't slip across the clearing.
More importantly... very hilly areas. It's not like the entire area is flat sand, that can easily be monitored from one vantage point (a high tower might work though).
Cleveland National Forest, Big Bend National Park, Coronado National Forest, Franklin Mountains State Park near Fort Bliss.
We can get some ideas of what parts of it looks like, thanks to Google street view from roads near the border in the US..:
Example0,
Example1,
2,
3,
4,
5, 6,
Slashdot Mirror
That depends. Security against what type of threat?
Perhaps. The jury is still out on that front, and it will be at least 6+ months, before it can be known for sure.
Windows 7 has improved defaults, such as the requirement for users to 'elevate' to perform Administrative functions. Helps protect against unintentionally running a program.
Reducing the number of users who will accidentally run malicious code, and UAC is an improvement, but not a robust security improvement really -- the user education in UAC has not gone far enough. When the threat is misguided, misinformed, or conned users, UAC is a pretty feeble improvement.
Also, I am not sure that "Making it harder for users to run as Administrator", and imposing it by default counts as a better security. You could do this even in XP, in an IT environment, don't give users Administrator rights to their own workstations, setup suitable NTFS file permissions.
Do user interface changes to reduce user mistakes count as security improvements? No, they count as better education for humans.
Still, on the vulnerability front, the attack surface is still as large as before, and there are many reasons to suggest a large number of vulnerabilities will eventually be discovered in this behemoth OS, just as they were found in XP.
I believe we can expect more in the same vein as the SMB v2.0 MS09-050 vulnerability, in the near future, and more local user privilege escalation holes as well.
Hm... sounds like a job for some firmware hacking.
Tweak the phone's code so it will refuse to disable encryption when "asked to"
Although it might be a bit useless to do so now, given the fact that GSM has just gotten pwned.
Viable is one thing.. efficient is quite another.
Wireless ad-hoc networks exist at a tiny fraction of the scale of botnets.
P2P is definitely more complicated, and the very process of trying to discover other nodes could reveal the existence of a bot...
How do you define "unusual/anomalous" traffic ? Like when I host an online shop, and I get a lot of traffic on the 9494 (no, it's not that port, only an example) port where I keep my jsonrpc server ?
No.. but if you had never generated any 9494 traffic before, and suddenly generate a huge volume of it to a bunch of Korean IP addresses (from a US-based server), that might be considered a bit suspicious.
I would guess, in most cases, the ISP would probably ignore port 9494 traffic, unless, say it was udp 9494 at a 500,000 packets per second rate..
Also, if you started generating traffic to some known compromised/botnet hosts...
No... that's not an issue the operators need be concerned with. The government can listen in regardless, through FISA, CALEA, Patriot Act, Lawful Interception technologies on the carrier's networks.
I wish I could elaborate further on the matter, but that's a dangerous proposition.
One reason to stick with simpler encryption technology, is it's a cheaper, commodity part. New algorithms take time to develop: R and D costs, mean more expensive products, not to mention the requirement to replace expensive network infrastructure in order to adopt new standards.
I'm more concerned about compromise of the user authentication process.
In the worst case it could result in the ability of an eavesdropper to capture your subscriber ID, and make international roaming calls as you, so they avoid racking up expensive charges themselves.
Plotting traffic, and destinations, in the aggregate is standard practice, get over it.
Ever hear of IPFIX, Netflow? If you send 100 gigs a day over port 25, to umpteen thousand destinations, you bet your ISP should consider looking into that, if the traffic is unusual/anomolous.
Looking at specific packets, or capturing sessions, I think is unlikely for ISPs to do in most cases, unless nefarious activity is already strongly suspected in those packets.
It's not realistic due to the amount of bits most ISPs transferred, they would need massive storage capacity to hold even a few hours of traffic.
The only way I think ISPs ever do take detailed looks into your packets, or some connections' packets is using automated tools: deep packet inspection, primarily, to detect and throttle Peer to Peer traffic (such as BitTorrent).
It is conceivable that some day, someone might make a "Botnet CnC detector" appliance, however.
Don't hold your breath. [Although I am still hopeful], It has not been demonstrated (yet) that any version of Windows ever developed or that will ever be developed has robust security.
I think it's so hard to develop good peer-to-peer network structure that it might not happen.
There aren't that many truly peer-to-peer networks that have ever succeeded.
I'd say the Internet itself, but even the Internet has to have DNS...
Something central has to give you a starting point, at least.
I've yet to see any peer to peer network technologies that don't require a "seed list" of some central nodes to initially connect to the network.
If you see a lamp on the ground and the couch burning through your neighbor's front window, is there a problem with you opening the front door, and dragging a bucket in, to douse the flames?
Yeah, I guess they could have you thrown in jail for barging in like that, and getting some water on their rug....
A warning in the form of a picture of Rick Astley?
It's not that hard... there are free encryption libraries, many cheap authenticators, stream ciphers, e.g. Poly1305-AES, Salsa20/8, Curve25519, Rabbit, Blowfish, for actual data. No need to use AES-768 here.
Actually, message encryption isn't required to protect against command hijacking, only digital signing and public key authentication (using a MAC) which is extremely cheap, and easy to do, thanks to open source OpenSSL and also, crypto libraries built into Windows.
server digitally signs a MAC / message hash with DSA, client authenticates only the hash, then validates the message matches the hash.
I think the only reason botnet operators aren't widely using message authentication, is they know, security researchers rarely go on the offensive, there might be legal issues with tampering with their code, AND:
There's no point in trying to defeat security researchers, with digital signatures.
Security researchers are essentially hackers themselves -- bringing in bloat like cipher code makes it probable the security researchers can find a buffer overflow, or other exploitable element in the botnet code itself, thus the bloat involved to digitally sign things becomes self-defeating.
What do you mean, you're harmless?
Someone living off the grid might take up other crimes to sustain themselves, since they can't get a legit job, apparently.
One successful heist or smuggling operation, and they're raking in the dough...
They can buy their modern lifestyle with cold hard cash.
Rent a place under a fake name, utilities under a fake name.
Well, this is not my area of expertise, I don't know exactly what works, and it might be different for different people.
But I expect they could live very comfortably.
Particularly should they move to another country (e.g. by sneaking across the border).
The lack of a treaty does not, but the law of that country might.
Also, even if an extradition arrangement is in place, it doesn't mean it will happen.
Many countries are unlikely to spend precious law enforcement resources to attempt to apprehend someone for anything short of a major crime.
In addition, they are not likely to do it unless the act is illegal in their own country, not a political crime, and the country they extradite to will respect the basic human rights of the prisoner (such as right to life)
Also, you can't extradite someone from another country, when you don't know which country they are living in, and they have gone to lengths to "blend in" and do nothing conspicuous.
Sure they might be in an extraditable country, but there are hundreds of countries in the world..
It's a small planet, but there are lots of places to hide.
Yeah, but how's he going to get the cash for transportation and credentials to get out of the country legally, without drawing attention?
Trying to cross the border or get on an airplane without a real ID/passport is pretty risky...
Part of the purpose of border security is to prevent such fleeing attempts.
Bazaar is a bit slow, but a great choice.
Git is a big mess in some ways (though still way better than using CVS), it's not better than Bazaar, too many commands, too many options, crappy windows support; Silly need for repository maintenance, ala git-gc; incomplete, unclear documentation. You can very easily shoot yourself in the foot with git, and accidentally destroy important history info (eg git-push --force), more so than any other version control system.
Mercurial is a lot closer to CVS/SVN in terminology, much easier for developers to adapt to. VCS should be simple, and it's really rather snappy.
Personally, I would say Bazaar is a fine choice for Emacs... if they should decide they need to change, they should switch to Mercurial and avoid Git like the plague it is :)
Never get deeply into either, operator overloading just obfusticates function calls, and in C++ is simply a twee excuse for not making strings a first class type, huge design error in C++, every idiot I see is writing a new string package, since it took years(decades) to get StdLib standardised
Overloading has useful applications for custom datatypes that have nothing to do with strings. I would agree beginners have no business worrying about it though. It's more like a thing you use if you are developing libraries for use by other programmers.
Examples: arbitrary precision math libraries, arbitrary length 'bitvector' classes.
I'm sorry you feel it inadequate about C++ not having a native string type, but this is by design.
C/C++ is widely deployed, and standardization for new versions takes a long time, as industry players get to duke it out.
Rolling your own string class or 'string wrapper' in C++ is very doable, sensible, and a better choice than using standard string, usually, as the StdLib string classes are fairly limited, have issues, and won't provide you with certain niceties, such as proper Unicode support.
It's just a fact that C++ standard classes are feeble, and you need to do something like this for almost every program (unless you re-use your same custom String class for every one, or use one provided by your standard framework such as QString (QT), which is recommended).
And the STL (Standard Template Library) is an even bigger embarrasment.
In addition, no pattern matching, case-insensitive search operations, no equivalent to Java String class options such as equalsIgnoreCase, regionMatches, etc. You can't do a basic case-insensitive compare with a straight-forward method name in C++.
The C++ string class is pretty much a feeble datatype with limited capabilities, and useless for real-world applications: it deserves to be re-invented, frequently.
I'd be surprised to see some programmer get along with just 'string' and no use of the c_str() method, or [] element accesses, for quick and dirty comparisons, using standard C functions, or using STL-inspired hacks and iterators on their string class.
Don't dare try to bring <algorithm> or <functor> into this. That's also a bad answer that C++ STL adds.
Needing to get at individual character elements to do such simple things as case-insensitive comparison, matching, search, OR common transformations (turn a string into all uppercase), is a very bad answer, C++ StdLib string class sucks: in fact, it makes C's StdLib string functions look supreme by comparison.
A little new simple code that might need to be debugged, is better than complex code bringing template specializations and elaborate STL algorithms, custom loops, too.
I'd rather debug a custom string class with a few added methods for case-insensitive compares, then compare thousands of places throughout code, where a standard string class was used with a tight loop, eg
string a, b="blah";
...
....
for(it j = 0; j < a.length; j++)
if (j >= b.length || a[j]!=tolower(b[j]))
goto they_dont_match;
The problem with BASIC is it is not structured programming, and the syntax is a mess.
And GOTO is an integral statement in any attempt to implement a computer algorithm in BASIC, which is the bane of structured programmers.
Using English words for certain things as in VB is reminiscent of COBOL, the syntax is more complicated than other programming languages, and the control structures are abysmal and difficult for a beginner to use.
Real programming, even at the novice level, uses structured languages. Which, by the way, is a lot more elegant, structurally simple, logically simpler, and easier for a beginner to deal with than BASIC.
Many beginners interested in computers, give up programming altogether, after being exposed to the horror that is BASIC.
It's fine that some folks make a good living playing with VB.
I'm saying that VB is more complicated, and is more suitable for advanced programmers. The language is not suited for teaching beginners.
It's really easy to get started, and there's an online, interactive ruby tutorial
And neither would others.
PASCAL.. mediocre choice. C, okay... C++.. if you insist.
Python: pretty good, Ruby, Ada: great, Haskell/SCHEME/LISP/ML: EXCELLENT
Well, some portion of the people who want to illegally migrate across the border, may already be able to cross legally..
But not with the drugs or other contraband they want to smuggle across.
Smuggling rings like this, may very well be able to afford high-tech gear, as it is. (I suppose) it just depends on what their profits have been in the past, and to what length they will go through.
I suspect radar, infra-red camouflage, and all sorts of fancy gear are not out of the question, as long as they can get access to it while in the US.
Um... many areas of the border are indeed Desert or near-Desert, but that doesn't mean no vegetation or trees. There are several areas near the border where there might be significant vegetation to conceal immigrants.. portions have been cleared, but that doesn't necessarily mean an immigrant won't slip across the clearing.
More importantly... very hilly areas. It's not like the entire area is flat sand, that can easily be monitored from one vantage point (a high tower might work though).
Cleveland National Forest, Big Bend National Park, Coronado National Forest, Franklin Mountains State Park near Fort Bliss.
We can get some ideas of what parts of it looks like, thanks to Google street view from roads near the border in the US..: Example0, Example1, 2, 3, 4, 5, 6,
Well, they could provide updates in a staggered fashion.
Example: Your IP address saw the footage at time X. The next footage your IP address will see from that camera will be at time X+n.
Where 'n' is some random number between 5 and 10 minutes, whatever 'n' necessary to screw up your timing attempt.
Different people accessing the camera will see different 'time offset' selected randomly.
So when there are 30 - 40 people watching the same camera there will be continuous coverage.. but one person can't see every moment.
If the feed is 30-60 second delayed, or updated less often when motion is not detected, it can still be useful.
It's not as if a large amount of movement can occur in 1 or 2 minutes, across such a wide view.
Please. This isn't even slightly tricky. Time the sunset / shadows. That gives you the east-west position (and very accurately, too.)
You can't time the sunset/shadows when you can't see shadows..
It's not necessarily clear how frequently the video feed is updated, and how much delay there is between real-time and what is shown.
Attempts to "time" the sunset accurately may not be feasible at all..
What methodology do you suggest could be used to do such a thing?