You seem to presume an unchecked environment where operations just continue with ruined data. However, in a more professional runtime environment such an integer overflow is causing an exception which can be handled in more or less successful ways. One would assume that systems used to provide evidence in legal procedures have the facilities to protect them against using invalid data because of variable overflows etc.
There probably was an integer overflow during the conversion of a floating point to a fixed point number, which shut down the primary control system and the backup shortly after eachother (because they were running the same software) and sent the vehicle offcourse.
The way it is implemented here in the Netherlands is that cookies required for technical operation, like login sessions, store baskets, user preferences are allowed but cookies used for other purposes, like tracking site visits and controlling ad placement, are not. (unless allowed explicitly by the user)
What is required now is an extra field in the cookies that conveys cookie intent, and a setting screen in the browser to allow/deny cookies with given intent (as a default). So users can opt-out of tracking and still be able to login and shop without having to confirm their cookie acceptance for every site.
Of course whitelisting cookies by site is useless. Many sites send different cookies, you want to block some of them but not all. Blocking by name is difficult because there is no name convention. When every session cookie would start with SESS and every tracking cookie with TRK, it would be easy. Now that there is no such naming convention, and no tools in place to do anything with cookie names, it is probably best to add another field to cookies, to convey cookie intent. Then users can allow or block cookies based on intent. They can allow cookies used to keep a login session, and refuse cookies used to track users.
Today's content providers seem to jump through every possible hoop to defeat caching. You would think that a video provider would use some indirect URL to first log the access attempt and then point to a static location where the actual video is provided, and that can be cached locally, but no... In a new deployment, including a caching proxy probably is a waste. E.g. our existing proxy now has a byte-% hit ratio of 11%, falling all the time.
So what you are saying is that today's equipment manufacturers are not as capable as the guys in the past were. Even with all the CPU power and memory they have available they are not able to code a decently performing system. They probably have different priorities than a fast and slick result, today.
With a capable design team, it should be possible to design a well working digital broadcast news system, even today.
It clearly shows that you are being fed shit. There is no such thing as "Ceefax has to go because analogue tv ends". It is a decision made for other reasons.
Yes, the cutoff of Ceefax appears to be politically or financially motivated, certainly not technically. The DVB system for digital TV transmission supports Teletext (Ceefax) just fine.
I think you are discussing implementation in your particular equipment, not features of the system. When teletext first appeared, its limitation were the same. You could type in a page number and then you needed to wait some 30 seconds before it appeared in the carroussel and you got it on screen. But then, TV sets appeared that loaded pages in memory ahead of them being requested. First a limited system with 4 or 8 "related" pages being loaded, later the entire page repertoire was kept in memory for instant recall. Apparently you have such a set and teletext is instaneous for you. But any followup system (that is not interactive) could do the same thing. Apparently your new device does not have the memory capacity or cleverness to do this, but a better device could be built that operates the same way as your teletext set.
What all you Britons should know is that there is no technical reason why you don't get Ceefax after the digital switchover. The digital system has support for TXT and in many other countries, including the Netherlands, the TXT service has remained in place after digital switchover, which was completed years ago here. There must be some political or financial reason why your BBC is dropping Ceefax. It has nothing to do with the digital switchover as it is.
Of course when someone had deleted half of the data in your finance database and you would notice it on the year or month close, you would already have overwritten all your backup media and lost your data forever.
Some time, someone will come at your desk and ask "I'm sure I had that contract in my documents folder last year but when I look now it has vanished". At that moment you will realize that your backup rotation scheme is not as clever as you first believed.
I'm not sure how everyone gets so ecstatic about those cloud backups. When we would need to send all our data over the internet connection it would take an unworkable amount of time to complete the backup. Even to the local LTO-4 drive, which runs at over a gigabit per second, the backup takes an appreciable amount of time. Cloud backup may be good for a 3-man company doing document editing, but with the amounts of data that are common these days, and the speeds of internet connection that you normally have, I don't see it as a realistic possibility.
RAID is not a replacement for a backup. RAID will safeguard you against the failure of a single disk (if and only if you monitor the system and replace disks as they fail), but backup will give you back your data as it was before your application destroyed it or your user deleted it. That is something completely different.
What people apparently don't realize is that there are way too many features in PDF to do a quick and dirty viewer. It will probably work on some simple PDFs created by a "print to PDF" tool, but once you start viewing more advanced PDFs you will be in trouble. Some time ago we switched from Adobe Reader to a competitor PDF reader where I work, and we still encounter PDFs that view OK in Adobe but fail in the new viewer. Especially (but not only) PDFs that contain user fillable forms cause trouble.
The experience is much like using another browser than Internet Explorer was 5 years ago. Often it worked, but frequently you encountered pages that won't render or function correctly.
The thing is that it does not matter at all how secure the organization you buy your certificate from is. What matters is how secure the lease secure of those hundreds of organizations that sell certificates is. You can buy your certificate from the most secure one, but someone else can buy or steal it from the least secure organization and it will be trusted just as much.
To revoke the DigiNotar intermediate, a browser that has OCSP or CRL does not need an update. At least if it is formally revoked by Dutch state (which it isn't, AFAIK).
The updates are only required for root certificate revocations, apparently there is no OCSP or CRL for those (something that should be fixed). But Mozilla is not distrusting the certificates based on revocation, but guided by the "CN=DigiNotar" in their issuer field. That is why they need to upgrade the code.
In fact it is ugly, hardcoded exceptions for specific mishaps are being added to the software. Something should be done that enables control of this kind of mishaps without having to update the software.
E.g. at work we have a Mozilla Seamonkey 2.0 deployment that I cannot yet upgrade to 2.3 because of bugs in that version and there are no updates to 2.0 released anymore. Of course OCSP is enabled, but it would be better if it also worked for root certificates.
They should, but they haven't done that yet. There is a security bulletin 2607712 that explains what they did for Vista and newer, but for XP and 2003 they should release a new version of rootsupd.exe that will update the list of root certificates. This is not an update to IE but to a separate Windows component that stores the root certificates.
This was probably mainly said because DigiNotar itself publishes a FAQ that basically says "when the browser says the certificate is not to be trusted you must select the option to trust it anyway because 99.9% of the certifcates are to be trusted". The Dutch government wants to warn citizens that this is very bad advise from DigiNotar, and that sites should never be used when this warning appears. In fact there is a campaign from banks to warn users that they should always take attention to certificate warnings, and any official advise to ignore them is to be considered a very bad thing.
Of course DigiNotar does not understand "trust" at all. In their FAQ and press releases they apparently have the opinion that trust in the certificates is something they define themselves, while of course trust is something the user grants to the CA. When the user no longer trusts the CA, the CA is finished no matter how many times it declares that it is to be trusted.
But DigiNotar is not interested in the users or the victims of their actions. They are only interested in their own company and its revenues. This was already clear in the first press release they did, where they dared to include a paragraph that downplayed the effect of all this on their revenue and share value. Let's see how this works out in practice. My prediction is that it will be worse than they claim.
Slashdot Mirror
When it travelled east to west, it most likely wasn't human-made space debris.
You seem to presume an unchecked environment where operations just continue with ruined data.
However, in a more professional runtime environment such an integer overflow is causing an exception which can be handled in more or less successful ways.
One would assume that systems used to provide evidence in legal procedures have the facilities to protect them against using invalid data because of variable overflows etc.
There probably was an integer overflow during the conversion of a floating point to a fixed point number, which shut down the primary control system and the backup shortly after eachother (because they were running the same software) and sent the vehicle offcourse.
The way it is implemented here in the Netherlands is that cookies required for technical operation,
like login sessions, store baskets, user preferences are allowed but cookies used for other purposes,
like tracking site visits and controlling ad placement, are not. (unless allowed explicitly by the user)
What is required now is an extra field in the cookies that conveys cookie intent, and a setting screen
in the browser to allow/deny cookies with given intent (as a default).
So users can opt-out of tracking and still be able to login and shop without having to confirm their
cookie acceptance for every site.
Of course whitelisting cookies by site is useless. Many sites send different cookies, you want to block some of them but not all.
Blocking by name is difficult because there is no name convention.
When every session cookie would start with SESS and every tracking cookie with TRK, it would be easy.
Now that there is no such naming convention, and no tools in place to do anything with cookie names, it is probably best to add
another field to cookies, to convey cookie intent. Then users can allow or block cookies based on intent. They can allow
cookies used to keep a login session, and refuse cookies used to track users.
On a properly managed company system, the administrator has turned off the possibility to run executables from removable media.
Easy.
When an office system executes programs from an external USB stick, it is just badly managed by the IT department.
In fact, Windows offers more control over features like this (via group policy) than most other systems.
Today's content providers seem to jump through every possible hoop to defeat caching.
You would think that a video provider would use some indirect URL to first log the access attempt and then point to a static location where the actual video is provided, and that can be cached locally, but no...
In a new deployment, including a caching proxy probably is a waste.
E.g. our existing proxy now has a byte-% hit ratio of 11%, falling all the time.
That is the HBBTV system.
So what you are saying is that today's equipment manufacturers are not as capable as the guys in the past were.
Even with all the CPU power and memory they have available they are not able to code a decently performing system.
They probably have different priorities than a fast and slick result, today.
With a capable design team, it should be possible to design a well working digital broadcast news system, even today.
Yes, and there also still is page 888, isn't it?
It clearly shows that you are being fed shit.
There is no such thing as "Ceefax has to go because analogue tv ends".
It is a decision made for other reasons.
Yes, the cutoff of Ceefax appears to be politically or financially motivated, certainly not technically.
The DVB system for digital TV transmission supports Teletext (Ceefax) just fine.
I think you are discussing implementation in your particular equipment, not features of the system.
When teletext first appeared, its limitation were the same. You could type in a page number and then
you needed to wait some 30 seconds before it appeared in the carroussel and you got it on screen.
But then, TV sets appeared that loaded pages in memory ahead of them being requested. First a limited
system with 4 or 8 "related" pages being loaded, later the entire page repertoire was kept in memory for
instant recall. Apparently you have such a set and teletext is instaneous for you.
But any followup system (that is not interactive) could do the same thing. Apparently your new device
does not have the memory capacity or cleverness to do this, but a better device could be built that operates
the same way as your teletext set.
What all you Britons should know is that there is no technical reason why you don't get Ceefax after the digital switchover.
The digital system has support for TXT and in many other countries, including the Netherlands, the TXT service has remained in
place after digital switchover, which was completed years ago here.
There must be some political or financial reason why your BBC is dropping Ceefax. It has nothing to do with the digital switchover
as it is.
Wait until your boss deletes that important document and your RAID system has deleted it on all drives in the array immediately at his request.
Or your business application is slowly corrupting the database and it is noticed (or finally confirmed) only after 3 weeks of use.
At that time you want to be able to get old data back. This is not something your array is going to be able to provide you.
Of course when someone had deleted half of the data in your finance database and you would notice it on the year or month close, you would already have overwritten all your backup media and lost your data forever.
Some time, someone will come at your desk and ask "I'm sure I had that contract in my documents folder last year but when I look now it has vanished".
At that moment you will realize that your backup rotation scheme is not as clever as you first believed.
I'm not sure how everyone gets so ecstatic about those cloud backups. When we would need to send all our data over the internet connection it would take an unworkable amount of time to complete the backup.
Even to the local LTO-4 drive, which runs at over a gigabit per second, the backup takes an appreciable amount of time.
Cloud backup may be good for a 3-man company doing document editing, but with the amounts of data that are common these days, and the speeds of internet connection that you normally have, I don't see it as a realistic possibility.
RAID is not a replacement for a backup.
RAID will safeguard you against the failure of a single disk (if and only if you monitor the system and replace disks as they fail), but backup will give you back your data as it was before your application destroyed it or your user deleted it. That is something completely different.
What people apparently don't realize is that there are way too many features in PDF to do a quick and dirty viewer.
It will probably work on some simple PDFs created by a "print to PDF" tool, but once you start viewing more advanced PDFs you will be in trouble.
Some time ago we switched from Adobe Reader to a competitor PDF reader where I work, and we still encounter PDFs that view OK in Adobe but fail in the new viewer.
Especially (but not only) PDFs that contain user fillable forms cause trouble.
The experience is much like using another browser than Internet Explorer was 5 years ago.
Often it worked, but frequently you encountered pages that won't render or function correctly.
Well, you have one very simplistic view of "backup"...
I would not talk about crusty old IT departments if I were you...
Probably the number of addresses in the utilized Internet that are intended to send mail is much lower than that 20-30%.
So it could still be a good method.
The thing is that it does not matter at all how secure the organization you buy your certificate from is.
What matters is how secure the lease secure of those hundreds of organizations that sell certificates is.
You can buy your certificate from the most secure one, but someone else can buy or steal it from the least secure organization and it will be trusted just as much.
To revoke the DigiNotar intermediate, a browser that has OCSP or CRL does not need an update. At least if it is formally revoked by Dutch state (which it isn't, AFAIK).
The updates are only required for root certificate revocations, apparently there is no OCSP or CRL for those (something that should be fixed).
But Mozilla is not distrusting the certificates based on revocation, but guided by the "CN=DigiNotar" in their issuer field.
That is why they need to upgrade the code.
In fact it is ugly, hardcoded exceptions for specific mishaps are being added to the software.
Something should be done that enables control of this kind of mishaps without having to update the software.
E.g. at work we have a Mozilla Seamonkey 2.0 deployment that I cannot yet upgrade to 2.3 because of bugs in that version and there are
no updates to 2.0 released anymore. Of course OCSP is enabled, but it would be better if it also worked for root certificates.
They should, but they haven't done that yet.
There is a security bulletin 2607712 that explains what they did for Vista and newer, but for XP and 2003 they should release a new version of rootsupd.exe that will update the list of root certificates.
This is not an update to IE but to a separate Windows component that stores the root certificates.
This was probably mainly said because DigiNotar itself publishes a FAQ that basically says "when the browser says the certificate is not to be trusted you must select the option to trust it anyway because 99.9% of the certifcates are to be trusted".
The Dutch government wants to warn citizens that this is very bad advise from DigiNotar, and that sites should never be used when this warning appears.
In fact there is a campaign from banks to warn users that they should always take attention to certificate warnings, and any official advise to ignore them is to be considered a very bad thing.
Of course DigiNotar does not understand "trust" at all. In their FAQ and press releases they apparently have the opinion that trust in the certificates is something they define themselves, while of course trust is something the user grants to the CA. When the user no longer trusts the CA, the CA is finished no matter how many times it declares that it is to be trusted.
But DigiNotar is not interested in the users or the victims of their actions. They are only interested in their own company and its revenues. This was already clear in the first press release they did, where they dared to include a paragraph that downplayed the effect of all this on their revenue and share value.
Let's see how this works out in practice. My prediction is that it will be worse than they claim.