Actually, sorry. Inadequate access controls and credential security on the wireless control network and insufficient encryption of data channels is an even worse situation indicating an even greater level of incompetence (or lack of existence) of network security staff.
Wireless control networks are inherently dangerous. When an employee is released, their credentials must be made invalid immediately, and the encryption keys should be changed frequently.
Competence is the problem. If they're not competent enough with IP on Ethernet to secure it and design it to prevent internet access, what hope do they have of properly securing their DECnet or SNA infrastructure, and yet still being able to manage it all?
They can make sure internet connectivity is impossible by using IPv6 only, implementing 802.1x with strong L2 switch security options, using an ample number of subnets, not connecting routers to the internet (or using ACLs both upstream and downstream to block aggressively).
And without anything so exotic and questionable as DECnet.
computer viruses have caused personnel injuries and production losses on North Sea platforms
They run Windows-based control software, and don't take the most basic security precautions such as banning web browsing and operators from executing unsigned files on management consoles?
You do realize, that even in the standard edition of Windows server 32-bit, you are limited to 4GB ?
You have to pay extra for the Enterprise version of Windows server, to get PAE enabled to utilize more than 4GB.
Therefore, in the Windows server platform, even, it is a licensing restriction.
Also, Windows XP 32-bit drivers seem to work just fine on that platform. I have not yet seen such an install encounter issues of any sort that turning off PAE resolves.
In a system with 4GB (or more of RAM), the first 2GB of address space (virtual memory address ranges 0x0 to 0x7fffffff) are for kernel memory, and the rest of the address space (0x80000000 and up) is user memory.
Operating system code and drivers are loaded into memory that is mapped from the kernel address space.
These predictably load (while your system is booting) into the lower physical memory addresses.
It's not that simple. The 20% causing the congestion make the network unusable for other services, so that the others can't use the network to do what they want.
For example, VoIP telephone services are unusable if there is any significant amount of packet loss or jitter, or if latency is too high.
The 20% of the population using 90% of the bandwidth hurt the quality of the service
of people who the network is really important to, because the people not using large amounts of bandwidth aren't simply sending as many bits as they can down the wire (like transferring bulk data); instead they are transferring small parcels of very important data.
And the moment providers start thinking about offering QoS services to prioritize these people's small 256-kilobit data streams for sending voice and video; the Bittorrent users are screaming bloody murder, and whining to the FCC about how X bid bad provider added a few minutes of extra time to their bulk download spree, how dare they!
In the long run, imposed "network neutrality" is bad for us as a society.
It means 20% of the population can hog 90% of the network resources without any technical measures being allowed to stop them.
Therefore, it is at best a band aid
The real sustainable solution is the one that should be put into law, not net neutrality.
The real solution is one that helps make sure the resources and ability is there for other companies to compete against their connectivity offerings.
Require monopolists offer interconnection to other ISPs on net neutral terms at a reasonable price (no more than X% above fair market), but don't require all connections (or consumer connections) are on those terms.
The 'crappy drivers excuse' is plain FUD. When PAE is enabled, driver code doesn't operate in PAE space.
The extended address space is used by apps' user memory area, not drivers, that get loaded in kernel memory.
Device drivers don't and shouldn't be aware of the extended memory areas, they only need to know about the address spaces used for DMA operations.
If it were an issue, Microsoft could very easily leave PAE off by default, and only allow it to be turned on when all your drivers are properly WHQL certified for PAE installs.
And archiving it on computers for later analysis.
Along with the documented believed position and placement of the camera
There's so much footage probably, that it needs to be analyzed using automated means to solve crimes with it; they almost certainly couldn't afford to have humans watching every second of film and scouring them for anything relevant to all crimes known and unknown; it would require simply superhuman abilities.... they need a smart AI, they need Hal 9000.
Is that really all that typical? I drive 15 miles a day, max.
And don't have to pay for parking. Most employers own parking space.
So, the only way you pay for parking is if you need to park in front of a store, on city property.
And even then, cities provide free parking space in many places, it's generally only certain areas where there is a fee.
Parking fees are not charged to discourage driving, they are charged to generate revenue for the city in highly-frequented areas. They also serve to reduce contention for limited parking space, which provides order, discourages dallying, and may actually increase business.
They may have a side-effect of discouraging parking in front of stores, and therefore, discouraging business to those stores, also.
But if they were that concerned about it, the stores should have purchased additional land and provided parking space for their customers.
This is not about cars or congestion on the road, it's about contention for a limited resource (parking space), because most land in cities is purchased and used for building store fronts, instead of leaving it bare.
The contention is so high, that not only can cities charge, but running a private for-pay parking lot can be a highly profitable business in its own right.
It's unlikely they use that type of sensor; they are expensive sensors and would have had to be installed in advance of laying down the asphalt.
There are much cheaper options that are more likely to be used.
The most common sensor for traffic lights measures change in the electromagnetic field when a car is moving over the loop.
If a car stays there stationary, the sensor won't trip.
You can possibly defeat such a sensor as you are leaving, by producing an artificial magnetic field and controlling the rate of change to avoid tripping the sensor as you leave.
But when you are gone and a new car arrives, it would almost certainly trip that type of sensor.
Your only real option to deal with that is to place material over the road to actually shield against any magnetic fields. This type of addition will be very noticable to city workers / enforcement officers.
OR to disable the sensor, by physically tampering with the metter (which is illegal, would take a while, and you would very likely get caught by the meter maids).
If they have sensors, they should make my clock stop when I leave, and let me use up the rest of my time the next time I park at a comparable place in the city.
If I leave 10 minutes later, only 10 minutes should be subtracted.
They have a central system now, and it's computerized, they can track these things down to millisecond resolution, no excuses!
Now being able to get your app signed for testing and loaded on your own hardware, requires you had joined the iPhone Developer program; $99/year membership fee for standard level (individuals only), or $299/year for enterprise level (corporations).
iPhone Developer program has its own agreement, whose exact contents are secret, but warranties of all types are disclaimed. Merchantability is explicitly disclaimed, you have to agree to that before you pay the fee to become a member of the iPhone developer program.
Moreover, even if your app is rejected or held in limbo, you are still provided other services by the program, and can attempt to submit another app in the future which may be accepted.
iPhone Developer Program includes things like access to pre-release iPhone software, access to Apple developer support, a digital signature for signing your app with, the ability (tools and codes) to load software onto your registered iPhone for testing.
Acceptance of the application you develop into the app store is not a service offered by the program that is included with the fee.
(Although they may not currently require additional fees to submit or additional fees when approved, they could start imposing that additional fee any time they so wished)
It's possible. In that case, by keeping the deals they make to different developers secret, they will have better negotiating power.
But this could also be more about Apple wanting control of what the media journalists, bloggers, and commenters on internet forums can say about Apple, their policies, and decisions. (E.g. the secrecy requirements may be "defensive" in nature, standard language they could use for all developer tools, possibly)
For example, if Google revealed certain information, it could result in the media publishing critical things about Apple.
Apple is very sensitive and aggressive in controlling their public image, and they are well known for their secrecy.
They are also well known for sending armies of lawyers at web sites or people revealing information they don't want puiblished, or that are excessively critical of them. Their tools include cease and decist letters, DMCA notices, threats to sue, and actual lawsuits....
Examples in recent years:
Apple Computer ordered to pay more than $750k in attorney fees and court costs in a case that pitted the electronics giant against a group of online journalists who posted information about an unreleased Apple product on the Web.
Apple sues Victoria School - over the use of a logo that is shaped like an Apple. [...] students are now afraid to give their teachers apples now because of the fruitâ(TM)s striking resemblance to the company logo.
The SDK agreement pertains to only development of applications using the SDK, and getting them signed for testing purposes, not actually getting apps accepted into the app store. Apple has other agreements that pertain to the app store.
You should check the iPhone Developer Program License Agreement
Yeah they are. It took me a while to find the SDK terms, on Wikileaks, but they must approve an app or withhold approval; they can't keep it in limbo.
No. Apple reserves the right to approve or withhold approval and digital signing. Digital signing is required just for testing an app. If they don't grant this approval, you can't even test the app, let-alone submit it to the app store for approval there.
Even if they utilize their right to grant approval for signing under the terms of the SDK, this does not give the app approval to be listed in the app store.
These terms don't mean they have to issue a rejection notice. They can withhold approval indefinitely, with always having the right to approve later.
Assuming your phone isn't being compromised, the bank could just call you on your telephone-number-of-record.
Isn't phone compromise just as plausible as computer compromise?
If you are a VoIP user, the hacker may use control of your computer to inspect packets to your VoIP handset, and intercept certain phone calls (specifically: ones from your bank).
There's also a (hopefully faint) possibility that a determined attacker who somehow got your personal identity details could signup for an account with an online VoIP provider like vonage (using a CC number stolen from you), get your number moved or ("ported") to their system, so the attacker now controls your phone number, get your phone company to assign you a new number, and perform a man-in-the-middle attack against your home phone.
Naturally, this just depends on how much of your information the criminal has stolen, before they can effectively impersonate you and get resources of yours temporarily under their control.
Re:You know you're being real-time keylogged when.
on
Real-Time Keyloggers
·
· Score: 1
Escaping that sort of detection is easy by not transmitting each individual keystroke in real-time. Maybe once every 4 or 5 keystrokes, or when you click, press enter, submit, space bar, or do something else that indicates a "text break".
In addition, they can attenuate this by sending a constant low-bitrate stream of data when you aren't typing anything, so your router's activity lights are always blinking.
E.g., they might transmit a 56-byte packet every 2 to 3 seconds, say something innoculous like a port 80 ping to windows update servers (or your distro's update servers for Linux users).
Needless to say, all the keystroke log transmissions would be encrypted and random fuzziness generated to make it hard for adversaries and network-based IDS to identify generated packets as keylogger traffic.
Banks do not widely use 2-factor authentication
on
Real-Time Keyloggers
·
· Score: 2, Informative
Two-factor authentication is when authentication requires two different factors of authentication. Some possible factors of authentication are something you know (PIN numbers, passwords, usernames, secret answers to questions arranged in advanced), something you have (smart card, key fob, pass-card, a special piece of hardware, a SSL certificate loaded on a device that you can't read), something you are (biometric identification, facial, voice, fingerprint recognition, hardware that reads your GPS position to verify you are at home, a phone number that checks your ANI caller ID information)
Most banks only require something you know. The security question/answer dialogs that are commonly used are equivalent to a second password, granted: a second password that is likely to be a lot less secure.
Issues like the 'temporary passwords' on your key fobs being discovered when you use them can be defeated, by only allowing the password to be used once. If an attempt to use the temporary password is used again, or an attempt is made to use any incorrect temporary password, then all active sessions should be logged out.
In addition both sessions should be warned about the attempt, and that their computer station may be compromised, they should update their antivirus and antispyware scanners, disconnect from the internet, and perform a full scan.
It seems you're the one going through great lengths to deny being wrong.
The quote doesn't add anything; we already know the obstacle takes up a space of a person, as in prevents a person from walking in towards the door along the path of the obstacle.
It makes no indications as to the size of the obstacle; obstacles that are much larger than a person may still take the space of a person along the evacuation paths shown in their model.
The article does not indicate the length, width, or height of the obstacle.
Though we may infer the size is at least that of a person, the description isn't clear enough to affirm that.
For the purposes of taking up the 'space of a person' for serving as a person-wide obstacle to evacuation a 5"x5"x25" box would do.
Until the additional work is done, the effect on the orientation and width, length, and height of the obstacle in the horizontal or the vertical must be considered unknown.
Slashdot Mirror
Actually, sorry. Inadequate access controls and credential security on the wireless control network and insufficient encryption of data channels is an even worse situation indicating an even greater level of incompetence (or lack of existence) of network security staff.
Wireless control networks are inherently dangerous. When an employee is released, their credentials must be made invalid immediately, and the encryption keys should be changed frequently.
Competence is the problem. If they're not competent enough with IP on Ethernet to secure it and design it to prevent internet access, what hope do they have of properly securing their DECnet or SNA infrastructure, and yet still being able to manage it all?
They can make sure internet connectivity is impossible by using IPv6 only, implementing 802.1x with strong L2 switch security options, using an ample number of subnets, not connecting routers to the internet (or using ACLs both upstream and downstream to block aggressively).
And without anything so exotic and questionable as DECnet.
computer viruses have caused personnel injuries and production losses on North Sea platforms.
In this day and age there aren't many DOS viruses floating around on closed systems.
computer viruses have caused personnel injuries and production losses on North Sea platforms
They run Windows-based control software, and don't take the most basic security precautions such as banning web browsing and operators from executing unsigned files on management consoles?
You do realize, that even in the standard edition of Windows server 32-bit, you are limited to 4GB ?
You have to pay extra for the Enterprise version of Windows server, to get PAE enabled to utilize more than 4GB.
Therefore, in the Windows server platform, even, it is a licensing restriction.
Also, Windows XP 32-bit drivers seem to work just fine on that platform. I have not yet seen such an install encounter issues of any sort that turning off PAE resolves.
In a system with 4GB (or more of RAM), the first 2GB of address space (virtual memory address ranges 0x0 to 0x7fffffff) are for kernel memory, and the rest of the address space (0x80000000 and up) is user memory.
Operating system code and drivers are loaded into memory that is mapped from the kernel address space.
These predictably load (while your system is booting) into the lower physical memory addresses.
It's not that simple. The 20% causing the congestion make the network unusable for other services, so that the others can't use the network to do what they want.
For example, VoIP telephone services are unusable if there is any significant amount of packet loss or jitter, or if latency is too high.
The 20% of the population using 90% of the bandwidth hurt the quality of the service of people who the network is really important to, because the people not using large amounts of bandwidth aren't simply sending as many bits as they can down the wire (like transferring bulk data); instead they are transferring small parcels of very important data.
And the moment providers start thinking about offering QoS services to prioritize these people's small 256-kilobit data streams for sending voice and video; the Bittorrent users are screaming bloody murder, and whining to the FCC about how X bid bad provider added a few minutes of extra time to their bulk download spree, how dare they!
In the long run, imposed "network neutrality" is bad for us as a society.
It means 20% of the population can hog 90% of the network resources without any technical measures being allowed to stop them.
Therefore, it is at best a band aid
The real sustainable solution is the one that should be put into law, not net neutrality.
The real solution is one that helps make sure the resources and ability is there for other companies to compete against their connectivity offerings.
Require monopolists offer interconnection to other ISPs on net neutral terms at a reasonable price (no more than X% above fair market), but don't require all connections (or consumer connections) are on those terms.
Example of several Windows distributions:
Windows XP
Windows XP Media Center Edition
Windows Server 2003
Same cat, different skin.
The 'crappy drivers excuse' is plain FUD. When PAE is enabled, driver code doesn't operate in PAE space.
The extended address space is used by apps' user memory area, not drivers, that get loaded in kernel memory.
Device drivers don't and shouldn't be aware of the extended memory areas, they only need to know about the address spaces used for DMA operations.
If it were an issue, Microsoft could very easily leave PAE off by default, and only allow it to be turned on when all your drivers are properly WHQL certified for PAE installs.
And archiving it on computers for later analysis. Along with the documented believed position and placement of the camera
There's so much footage probably, that it needs to be analyzed using automated means to solve crimes with it; they almost certainly couldn't afford to have humans watching every second of film and scouring them for anything relevant to all crimes known and unknown; it would require simply superhuman abilities.... they need a smart AI, they need Hal 9000.
The only place where you can really expect privacy is inside your home.
I think they're working hard on that angle too.
Looks like something a sawzall, or other power tools (and/or typical methods of freezing and breaking locks) would make quick work of...
you can't park and risk clamps
What are clamps?
Giant hands that come down from the sky and grab you, while you're traveling, or what?
Is that really all that typical? I drive 15 miles a day, max.
And don't have to pay for parking. Most employers own parking space.
So, the only way you pay for parking is if you need to park in front of a store, on city property. And even then, cities provide free parking space in many places, it's generally only certain areas where there is a fee.
Parking fees are not charged to discourage driving, they are charged to generate revenue for the city in highly-frequented areas. They also serve to reduce contention for limited parking space, which provides order, discourages dallying, and may actually increase business.
They may have a side-effect of discouraging parking in front of stores, and therefore, discouraging business to those stores, also.
But if they were that concerned about it, the stores should have purchased additional land and provided parking space for their customers.
This is not about cars or congestion on the road, it's about contention for a limited resource (parking space), because most land in cities is purchased and used for building store fronts, instead of leaving it bare.
The contention is so high, that not only can cities charge, but running a private for-pay parking lot can be a highly profitable business in its own right.
A developer would have a hard time arguing that there's an implicit contract, because of the fact that there's an explicit contract...
It's unlikely they use that type of sensor; they are expensive sensors and would have had to be installed in advance of laying down the asphalt. There are much cheaper options that are more likely to be used.
The most common sensor for traffic lights measures change in the electromagnetic field when a car is moving over the loop. If a car stays there stationary, the sensor won't trip.
You can possibly defeat such a sensor as you are leaving, by producing an artificial magnetic field and controlling the rate of change to avoid tripping the sensor as you leave.
But when you are gone and a new car arrives, it would almost certainly trip that type of sensor.
Your only real option to deal with that is to place material over the road to actually shield against any magnetic fields. This type of addition will be very noticable to city workers / enforcement officers.
OR to disable the sensor, by physically tampering with the metter (which is illegal, would take a while, and you would very likely get caught by the meter maids).
If they have sensors, they should make my clock stop when I leave, and let me use up the rest of my time the next time I park at a comparable place in the city. If I leave 10 minutes later, only 10 minutes should be subtracted.
They have a central system now, and it's computerized, they can track these things down to millisecond resolution, no excuses!
They don't sell the SDK, it's free.
Now being able to get your app signed for testing and loaded on your own hardware, requires you had joined the iPhone Developer program; $99/year membership fee for standard level (individuals only), or $299/year for enterprise level (corporations).
iPhone Developer program has its own agreement, whose exact contents are secret, but warranties of all types are disclaimed. Merchantability is explicitly disclaimed, you have to agree to that before you pay the fee to become a member of the iPhone developer program. Moreover, even if your app is rejected or held in limbo, you are still provided other services by the program, and can attempt to submit another app in the future which may be accepted.
iPhone Developer Program includes things like access to pre-release iPhone software, access to Apple developer support, a digital signature for signing your app with, the ability (tools and codes) to load software onto your registered iPhone for testing.
Acceptance of the application you develop into the app store is not a service offered by the program that is included with the fee. (Although they may not currently require additional fees to submit or additional fees when approved, they could start imposing that additional fee any time they so wished)
It's possible. In that case, by keeping the deals they make to different developers secret, they will have better negotiating power.
But this could also be more about Apple wanting control of what the media journalists, bloggers, and commenters on internet forums can say about Apple, their policies, and decisions. (E.g. the secrecy requirements may be "defensive" in nature, standard language they could use for all developer tools, possibly)
For example, if Google revealed certain information, it could result in the media publishing critical things about Apple.
Apple is very sensitive and aggressive in controlling their public image, and they are well known for their secrecy.
They are also well known for sending armies of lawyers at web sites or people revealing information they don't want puiblished, or that are excessively critical of them. Their tools include cease and decist letters, DMCA notices, threats to sue, and actual lawsuits....
Examples in recent years:
The SDK agreement pertains to only development of applications using the SDK, and getting them signed for testing purposes, not actually getting apps accepted into the app store. Apple has other agreements that pertain to the app store.
You should check the iPhone Developer Program License Agreement
Yeah they are. It took me a while to find the SDK terms, on Wikileaks, but they must approve an app or withhold approval; they can't keep it in limbo.
No. Apple reserves the right to approve or withhold approval and digital signing. Digital signing is required just for testing an app. If they don't grant this approval, you can't even test the app, let-alone submit it to the app store for approval there.
Even if they utilize their right to grant approval for signing under the terms of the SDK, this does not give the app approval to be listed in the app store.
These terms don't mean they have to issue a rejection notice. They can withhold approval indefinitely, with always having the right to approve later.
Assuming your phone isn't being compromised, the bank could just call you on your telephone-number-of-record.
Isn't phone compromise just as plausible as computer compromise?
If you are a VoIP user, the hacker may use control of your computer to inspect packets to your VoIP handset, and intercept certain phone calls (specifically: ones from your bank).
There's also a (hopefully faint) possibility that a determined attacker who somehow got your personal identity details could signup for an account with an online VoIP provider like vonage (using a CC number stolen from you), get your number moved or ("ported") to their system, so the attacker now controls your phone number, get your phone company to assign you a new number, and perform a man-in-the-middle attack against your home phone.
Naturally, this just depends on how much of your information the criminal has stolen, before they can effectively impersonate you and get resources of yours temporarily under their control.
Escaping that sort of detection is easy by not transmitting each individual keystroke in real-time. Maybe once every 4 or 5 keystrokes, or when you click, press enter, submit, space bar, or do something else that indicates a "text break".
In addition, they can attenuate this by sending a constant low-bitrate stream of data when you aren't typing anything, so your router's activity lights are always blinking.
E.g., they might transmit a 56-byte packet every 2 to 3 seconds, say something innoculous like a port 80 ping to windows update servers (or your distro's update servers for Linux users).
Needless to say, all the keystroke log transmissions would be encrypted and random fuzziness generated to make it hard for adversaries and network-based IDS to identify generated packets as keylogger traffic.
They use wish-it-was two-factor
Two-factor authentication is when authentication requires two different factors of authentication. Some possible factors of authentication are something you know (PIN numbers, passwords, usernames, secret answers to questions arranged in advanced), something you have (smart card, key fob, pass-card, a special piece of hardware, a SSL certificate loaded on a device that you can't read), something you are (biometric identification, facial, voice, fingerprint recognition, hardware that reads your GPS position to verify you are at home, a phone number that checks your ANI caller ID information)
Most banks only require something you know. The security question/answer dialogs that are commonly used are equivalent to a second password, granted: a second password that is likely to be a lot less secure.
Issues like the 'temporary passwords' on your key fobs being discovered when you use them can be defeated, by only allowing the password to be used once. If an attempt to use the temporary password is used again, or an attempt is made to use any incorrect temporary password, then all active sessions should be logged out.
In addition both sessions should be warned about the attempt, and that their computer station may be compromised, they should update their antivirus and antispyware scanners, disconnect from the internet, and perform a full scan.
It seems you're the one going through great lengths to deny being wrong.
The quote doesn't add anything; we already know the obstacle takes up a space of a person, as in prevents a person from walking in towards the door along the path of the obstacle. It makes no indications as to the size of the obstacle; obstacles that are much larger than a person may still take the space of a person along the evacuation paths shown in their model.
The article does not indicate the length, width, or height of the obstacle. Though we may infer the size is at least that of a person, the description isn't clear enough to affirm that.
For the purposes of taking up the 'space of a person' for serving as a person-wide obstacle to evacuation a 5"x5"x25" box would do.
Until the additional work is done, the effect on the orientation and width, length, and height of the obstacle in the horizontal or the vertical must be considered unknown.