Notaries are possibly the highest paid professionals in Italy, thanks to the government tightly limiting their numbers: http://www.economist.com/node/...
Re:The real WTF is the URL
on
The DIY Tank
·
· Score: 1
It's nice to see Kettering in the news. I'm anticipating to read see another article in a couple months when a Flintoid steals the tank over the long weekend.
Everyone should recognize that, for anyone who uses the HTTP redirects, there is no improvement in security. Just as login pages served using HTTP can potentially be maliciously altered, so can the HTTP redirects. Thus, an attacker could alter the redirect and send people to a lookalike site (potentially using the same domain, if they can control all HTTP traffic). Users who simply type in the bank domain in their address bar, have an old bookmark, use a link to the HTTP site, or use a link from an HTTP page are all still at risk.
However, there is a benefit from redirecting to HTTPS: user who bookmark the HTTPS site will never be exposed to the risks of HTTP when they use their bookmark.
Assuming the redirect is permanent, it should also cause links from search engines to go to the HTTPS site. While this prevents HTTP attacks on the banking site, the search engine pages were not served using HTTPS. Thus, the problem just moves one step earlier.
In short, I agree it's beneficial to use HTTPS for the whole site, but the benefit is limited.
I can't speak for the poster, but I believe "object-relational setups" refers to the use of O/R mappers and similar technology. They can be can quite useful... you can write your entire application in an OO language and get database independence to boot. It's a good way to avoid SQL.
I have seen a couple applications where dozens of classes were developed which exactly mirrored the database tables. All of this code disappears (or is automatically generated) if you switch to an O/R mapper.
Aren't you confusing scalability and availability?
My understanding is that scalability refers to the performance, and to improve scalability you look for bottlenecks that are causing slowness. Frequently these bottlenecks are helped by scaling up (buying a bigger, faster server) or scaling out (building a load-balanced cluster)
Availability is avoiding downtime and protecting against software faults (e.g. Apache crashed) and hardware faults (e.g. failed harddrives).
Sometimes certain configurations provide both scalability and availability, such as load-balanced clustering and certain RAID configurations. More often, scalability and availability are independent or even opposing goals. Having a standby database server will improve your availability but will not make your website any faster. The data replication would likely degrade performance just sightly.
Hardware faults can be protected against by using redundant electric circuits, redundant UPSes, redundant power supplies, redundant servers, RAID arrays, ECC memory, etc. Software faults are a little bit tricky. You can use something like Serviceguard clusters and a SAN to configure software packages that will detect software faults and failover between nodes, but even this wouldn't provide the automatically compensating transaction you described.
I work in the IT department for a utility company in the midwest. The people are friendly and things are generally low-stress. Most people still work here for life. The flip side is that we rarely use leading-edge technology, projects can progress very slowly, and some people are dead weight.
Slashdot Mirror
Notaries are possibly the highest paid professionals in Italy, thanks to the government tightly limiting their numbers: http://www.economist.com/node/...
It's nice to see Kettering in the news. I'm anticipating to read see another article in a couple months when a Flintoid steals the tank over the long weekend.
If only I had been reading /. at work today, I would have known why some of my company's e-mail started bouncing back!
Everyone should recognize that, for anyone who uses the HTTP redirects, there is no improvement in security. Just as login pages served using HTTP can potentially be maliciously altered, so can the HTTP redirects. Thus, an attacker could alter the redirect and send people to a lookalike site (potentially using the same domain, if they can control all HTTP traffic). Users who simply type in the bank domain in their address bar, have an old bookmark, use a link to the HTTP site, or use a link from an HTTP page are all still at risk. However, there is a benefit from redirecting to HTTPS: user who bookmark the HTTPS site will never be exposed to the risks of HTTP when they use their bookmark. Assuming the redirect is permanent, it should also cause links from search engines to go to the HTTPS site. While this prevents HTTP attacks on the banking site, the search engine pages were not served using HTTPS. Thus, the problem just moves one step earlier. In short, I agree it's beneficial to use HTTPS for the whole site, but the benefit is limited.
I have seen a couple applications where dozens of classes were developed which exactly mirrored the database tables. All of this code disappears (or is automatically generated) if you switch to an O/R mapper.
Simon,
Aren't you confusing scalability and availability?
My understanding is that scalability refers to the performance, and to improve scalability you look for bottlenecks that are causing slowness. Frequently these bottlenecks are helped by scaling up (buying a bigger, faster server) or scaling out (building a load-balanced cluster)
Availability is avoiding downtime and protecting against software faults (e.g. Apache crashed) and hardware faults (e.g. failed harddrives).
Sometimes certain configurations provide both scalability and availability, such as load-balanced clustering and certain RAID configurations. More often, scalability and availability are independent or even opposing goals. Having a standby database server will improve your availability but will not make your website any faster. The data replication would likely degrade performance just sightly.
Hardware faults can be protected against by using redundant electric circuits, redundant UPSes, redundant power supplies, redundant servers, RAID arrays, ECC memory, etc. Software faults are a little bit tricky. You can use something like Serviceguard clusters and a SAN to configure software packages that will detect software faults and failover between nodes, but even this wouldn't provide the automatically compensating transaction you described.
-David
I work in the IT department for a utility company in the midwest. The people are friendly and things are generally low-stress. Most people still work here for life. The flip side is that we rarely use leading-edge technology, projects can progress very slowly, and some people are dead weight.