Yeah - some ATMs in the UK still don't use magstripe, although the numbers are decreasing and their usually easy to identify (the displays look like something out of War Games).
Whenever I travel to the US, one of the first things that I notice is different is the lax approach to card security. In most of Western Europe, pretty much every card transaction uses the chip. I can disable the mag-stripe on some of my cards (through the banks' online systems), and using magstripe anywhere increases the chance of a transaction being picked up by the banks' automated fraud detection systems. Then when you get to the US, you go into a restaurant, settle up by card with no signature and no pin, and then the restaurant can manipulate the transaction later to add whatever tip you wrote on the bill. Madness!
I've been involved in negotiations with a couple of contracts relating to Google Apps for Enterprise/Education.
In each one, the "scanning" has been explicitly mentioned in the contract. In each one, scanning for the purposes of advertising has only happened if the domain administrator allows it to happen. If it is turned off, Google will not scan mail for the purposes of advertising content.
There are of course other reasons why google will scan your email. Spam/Antivirus filtering and indexing to enable search functionality are two that come to mind.
Basically, all Google have done is remove the domain administrators ability to allow ads, and I'm not aware of anyone I know who used Google Apps for Education/Enterprise with it turned on anyway.
The article doesn't make it completely clear that this doesn't have much to do with the fixing problems in OpenSSL.
Commits to the true OpenSSL source can be seen through the web interface at https://github.com/openssl/ope.... What the article is talking about is tidying up the version that is built in to OpenBSD. Not that that isn't worthwhile work, but it's unlikely to fix many hidden problems in OpenSSL itself, unless the OpenBSD devs find something and hand it back to the upstream.
Indeed. When we introduced our change management process I realised that I was informally doing this risk analysis anyway. The change management process and CAB just formalise it.
Risk analysis can be as simple as thinking "is this low impact" for a second and then deciding it is and continuing. Most of these types of changes are pre-approved by CAB and we just have to record the change. If we started creating outages from these types of changes then that pre-approval would probably be reviewed.
There are other times when that pre-approval is temporarily revoked when the organisation cannot tolerate the risk of any downtime caused by changes, but that only happens twice a year, and I get to put my feet up a bit and work on interesting hobby projects for a couple of weeks:) A few of my colleagues get irritated that they "can't get anything done", but if my employer chooses to stop me making changes and let me have a rest for a bit, I'm not going to complain!
It needn't difficult at all and it doesn't have to impact your ability to apply security patches. For example, patches from Microsoft released on the 8th April were applied to roughly 500 servers on the 11th. A couple of hundred of our servers applied the software remedy for heartbleed within hours of it being released, without any intervention from a human at all.
A change management process should take into account an organisations appetite for risk. For us, we're keen to apply security patches quickly, so they are pre-approved by our CAB.
I have to do this and it's no problem at all, although our change management process doesn't sound quite as onerous as yours (I suspect yours will adapt over time -- the CAB will soon get bored if they have to approve every single OS patch).
I have to do a risk analysis for each change that gets made to a system (not just patches). Sometimes this risk analysis is fairly informal, for example if the change is to add more RAM to a VM, it's very unlikely to have a significant adverse impact and is easily reversible, so low risk. Other times the risk analysis (and processes that come out of that) may take a long time and require significant co-ordination with other parts of the organisation I work in.
A good example is if we make a change to a service that impacts the look and feel of that service. It will require co-ordinating with our communications, helpdesk, training and documentation teams as well as other parts of the technical group I work in and the CAB really acts as a check to make sure all of that has happened properly.
There are still a few people in our organisation who see the CAB as a barrier to getting work done, but for me it is really a check to make sure we're delivering changes in a proper way.
I can recommend you take a look at The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. http://itrevolution.com/books/... - I had quite a few "this is where I work" moments whilst reading it:)
Do you mean GBIC? I'm not aware of them using LEDs. For optical GBICs lasers are used (usually VCSELs - or they were when I last cared about the internal workings of fibre stuff, which was about 10 years ago ).
That's still proxying and not NAT. I would be stunned if ISPs started routinely proxying all HTTP traffic (and they don't stand a chance with HTTPS). The amount of processing resource required would be unfeasibly large.
X-Forwarded-For won't help with CG-NAT. Any XFF: address would be a fairly meaningless RFC6598 address, and that's assuming that the ISP is running a proxy as well as CG-NAT.
Fifteen!? Luxury! From the UK you're looking at about 24 hours *flying* time, ignoring any time on the ground when you stop over somewhere in the middle. It's a good job I enjoy reading on flights:) Faster planes would be good... faster and more efficient planes would be amazing!
NetApp are being somewhat inconsistent. Their technical presentations and their website differ (possibly because it is more straightforward for them just to say "yeah, RAID-DP is RAID-6" because it is easy to understand).
If you consider RAID-6 to be the generic term for any dual-parity RAID protection, then sure, RAID-DP is RAID-6. However, the technical implementation is more like RAID-4 with two different parity calculations. The parity disks are dedicated rather than distributed.
The failure mode that is easiest to manage is when they completely fail.
Good luck to you with disks that fail silently over a long period of time, corrupting your data without you knowing about it.
Some correct fixes for this are combinations of RAID, backups, a filesystem that checksums data and metadata (BTRFS, WAFL, ZFS). Limping along on half knackered drives is probably one of the worst things you can do.
MAC address filtering is useless against a determined attacker. Your best bet is a WPA2 PSK with a long key, unless you fancy setting up WPA2 Enterprise.
Or, instead of thinking better of mugging little old ladies, Mike now carries a gun himself. Because he's a drug-addict, he doesn't adopt the same decent moral stance that you do on the use of guns. He's quite happy to shoot, because he's a used to an environment where little old ladies are legally able to pull out a gun and shoot him in the face.
It's my belief that by permitting guns as part of normal everyday society, an arms-race is started. The "bad guys" aren't worried about the legal use or ownership of guns (they're the bad guys remember, what's the problem with breaking just one more law!), so they're nearly always 1 step ahead.
Most cell towers are not omni-directional, they are segmented. It's quite common to have 3 or 6 separate segments on a cell.
It's possible to get quite an accurate arc depending on local configuration, from just a single segment. It improves significantly with two adjacent cells and dependent on the local configuration of the segments you could get a single location (dependent on whether the segment arcs intersect once or twice). The more segments per tower, the greater your chance you can pinpoint with just two towers.
Slashdot Mirror
Yeah - some ATMs in the UK still don't use magstripe, although the numbers are decreasing and their usually easy to identify (the displays look like something out of War Games).
Whenever I travel to the US, one of the first things that I notice is different is the lax approach to card security. In most of Western Europe, pretty much every card transaction uses the chip. I can disable the mag-stripe on some of my cards (through the banks' online systems), and using magstripe anywhere increases the chance of a transaction being picked up by the banks' automated fraud detection systems. Then when you get to the US, you go into a restaurant, settle up by card with no signature and no pin, and then the restaurant can manipulate the transaction later to add whatever tip you wrote on the bill. Madness!
Also free G-suite T&C's are different from paid/enterprise
Great! Build a storage service and sell it to us. See how far you get.
Go read the G-Suite T&Cs. They are not the same as the consumer Gmail product.
My girlfriend bought a new car and discovered the previous owner's Irish Folk Music CD in the CD player.
I've been involved in negotiations with a couple of contracts relating to Google Apps for Enterprise/Education.
In each one, the "scanning" has been explicitly mentioned in the contract. In each one, scanning for the purposes of advertising has only happened if the domain administrator allows it to happen. If it is turned off, Google will not scan mail for the purposes of advertising content.
There are of course other reasons why google will scan your email. Spam/Antivirus filtering and indexing to enable search functionality are two that come to mind.
Basically, all Google have done is remove the domain administrators ability to allow ads, and I'm not aware of anyone I know who used Google Apps for Education/Enterprise with it turned on anyway.
I did look at the commits. They're all to OpenBSD, not OpenSSL.
By "fixing SSL" I meant "fixing OpenSSL". Duh! :(
The article doesn't make it completely clear that this doesn't have much to do with the fixing problems in OpenSSL.
Commits to the true OpenSSL source can be seen through the web interface at https://github.com/openssl/ope.... What the article is talking about is tidying up the version that is built in to OpenBSD. Not that that isn't worthwhile work, but it's unlikely to fix many hidden problems in OpenSSL itself, unless the OpenBSD devs find something and hand it back to the upstream.
Indeed. When we introduced our change management process I realised that I was informally doing this risk analysis anyway. The change management process and CAB just formalise it.
Risk analysis can be as simple as thinking "is this low impact" for a second and then deciding it is and continuing. Most of these types of changes are pre-approved by CAB and we just have to record the change. If we started creating outages from these types of changes then that pre-approval would probably be reviewed.
There are other times when that pre-approval is temporarily revoked when the organisation cannot tolerate the risk of any downtime caused by changes, but that only happens twice a year, and I get to put my feet up a bit and work on interesting hobby projects for a couple of weeks :) A few of my colleagues get irritated that they "can't get anything done", but if my employer chooses to stop me making changes and let me have a rest for a bit, I'm not going to complain!
It needn't difficult at all and it doesn't have to impact your ability to apply security patches. For example, patches from Microsoft released on the 8th April were applied to roughly 500 servers on the 11th. A couple of hundred of our servers applied the software remedy for heartbleed within hours of it being released, without any intervention from a human at all.
A change management process should take into account an organisations appetite for risk. For us, we're keen to apply security patches quickly, so they are pre-approved by our CAB.
I have to do this and it's no problem at all, although our change management process doesn't sound quite as onerous as yours (I suspect yours will adapt over time -- the CAB will soon get bored if they have to approve every single OS patch).
I have to do a risk analysis for each change that gets made to a system (not just patches). Sometimes this risk analysis is fairly informal, for example if the change is to add more RAM to a VM, it's very unlikely to have a significant adverse impact and is easily reversible, so low risk. Other times the risk analysis (and processes that come out of that) may take a long time and require significant co-ordination with other parts of the organisation I work in.
A good example is if we make a change to a service that impacts the look and feel of that service. It will require co-ordinating with our communications, helpdesk, training and documentation teams as well as other parts of the technical group I work in and the CAB really acts as a check to make sure all of that has happened properly.
There are still a few people in our organisation who see the CAB as a barrier to getting work done, but for me it is really a check to make sure we're delivering changes in a proper way.
I can recommend you take a look at The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. http://itrevolution.com/books/... - I had quite a few "this is where I work" moments whilst reading it :)
"I took the initiative on creating the internet".
http://www.youtube.com/watch?v=BnFJ8cHAlco
Do you mean GBIC? I'm not aware of them using LEDs. For optical GBICs lasers are used (usually VCSELs - or they were when I last cared about the internal workings of fibre stuff, which was about 10 years ago ).
That's still proxying and not NAT. I would be stunned if ISPs started routinely proxying all HTTP traffic (and they don't stand a chance with HTTPS). The amount of processing resource required would be unfeasibly large.
X-Forwarded-For won't help with CG-NAT. Any XFF: address would be a fairly meaningless RFC6598 address, and that's assuming that the ISP is running a proxy as well as CG-NAT.
SHA-512 is a cryptographic hash function. Faster computation of hashes is exactly what you *don't* want.
Fifteen!? Luxury! From the UK you're looking at about 24 hours *flying* time, ignoring any time on the ground when you stop over somewhere in the middle. It's a good job I enjoy reading on flights :) Faster planes would be good... faster and more efficient planes would be amazing!
NetApp are being somewhat inconsistent. Their technical presentations and their website differ (possibly because it is more straightforward for them just to say "yeah, RAID-DP is RAID-6" because it is easy to understand).
If you consider RAID-6 to be the generic term for any dual-parity RAID protection, then sure, RAID-DP is RAID-6. However, the technical implementation is more like RAID-4 with two different parity calculations. The parity disks are dedicated rather than distributed.
The failure mode that is easiest to manage is when they completely fail.
Good luck to you with disks that fail silently over a long period of time, corrupting your data without you knowing about it.
Some correct fixes for this are combinations of RAID, backups, a filesystem that checksums data and metadata (BTRFS, WAFL, ZFS). Limping along on half knackered drives is probably one of the worst things you can do.
MAC address filtering is useless against a determined attacker. Your best bet is a WPA2 PSK with a long key, unless you fancy setting up WPA2 Enterprise.
Or, instead of thinking better of mugging little old ladies, Mike now carries a gun himself. Because he's a drug-addict, he doesn't adopt the same decent moral stance that you do on the use of guns. He's quite happy to shoot, because he's a used to an environment where little old ladies are legally able to pull out a gun and shoot him in the face.
It's my belief that by permitting guns as part of normal everyday society, an arms-race is started. The "bad guys" aren't worried about the legal use or ownership of guns (they're the bad guys remember, what's the problem with breaking just one more law!), so they're nearly always 1 step ahead.
Most cell towers are not omni-directional, they are segmented. It's quite common to have 3 or 6 separate segments on a cell.
It's possible to get quite an accurate arc depending on local configuration, from just a single segment. It improves significantly with two adjacent cells and dependent on the local configuration of the segments you could get a single location (dependent on whether the segment arcs intersect once or twice). The more segments per tower, the greater your chance you can pinpoint with just two towers.
have a bit more experience of running GSM networks over here!
By GSM, I also include UMTS.