Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Microsoft Software

Few of OOXML's Flaws Have Been Addressed 162

Posted by Zonk from the digging-under-the-hood dept.
I Don't Believe in Imaginary Property writes "IBM's Rob Weir has done a study on how many flaws were addressed by the OOXML Ballot Resolution Meeting. So far, using a random sampling technique, he has yet to find a flaw that was addressed, making the upper bound a paltry 1.5%. Even so, he's found a number of new flaws, including a security vulnerability: OOXML stores passwords in database connection strings in plain text. At least there were no mistakes on five of the first twenty five random pages he reviewed."
This discussion has been archived. No new comments can be posted.

Few of OOXML's Flaws Have Been Addressed More

Few of OOXML's Flaws Have Been Addressed

Comments Filter:

  • Corruption. (Score:5, Insightful)

    by twitter ( 104583 ) * on Wednesday March 19, 2008 @01:42PM (#22797654) Homepage Journal
    Why fix flaws when you can buy voters?

  • Office 2007 (Score:5, Interesting)

    by number6x ( 626555 ) on Wednesday March 19, 2008 @01:48PM (#22797738)

    Do any of these flaws exist in Office 2007?

    If not, why are they in the OOXML proposed standard. If the standard does not describe the OOXML format used by Microsoft, then what does it describe?

    Why can't they just document the format that they use and get this over with? Or are they doing all this for show, and there is no real substance in OOXML?

    • Re:Office 2007 (Score:5, Insightful)

      by corsec67 ( 627446 ) on Wednesday March 19, 2008 @01:52PM (#22797800) Homepage Journal
      Or are they doing all this for show, and there is no real substance in OOXML?

      The reason MS is bothering with ISO is because a few places have started to require that documents be stored in an ISO defined format.

      The problem is that having a true ISO defined format means that you open yourself up to competition, so MS wants to get their format defined as ISO certified without allowing any competition.

      • Re:Office 2007 (Score:5, Interesting)

        by TropicalCoder ( 898500 ) on Wednesday March 19, 2008 @02:48PM (#22798418) Homepage Journal

        You'll remember Stéphane Rodriguez who gave us Microsoft Office XML formats? Defective by design [blogspot.com] back in August, 2007?

        Since then, in February, 2008 he produced The truth about Microsoft Office compatibility [blogspot.com] and Typical B.S. in technical articles about OOXML [blogspot.com] and now Bad surprise in Microsoft Office binary documents : interoperability remains impossible [blogspot.com] Thursday, March 13, 2008.

        These blogs are at the same level of depth as Rob Weir's latest blog, and demonstrate that Microsoft's policies as detailed below continue to this day.

        From OOXML is defective by design...

        "Mr Bill Gates in person sent in 1998 a memo to the Office product group (led by Steven Sinofsky at the time), memo undisclosed to the public thanks to the IOWA consumer case :"

        From: Bill Gates

        Sent: Saturday, December 5 1998

        To: Bob Muglia, Jon DeVann, Steven Sinofsky

        Subject : Office rendering

        One thing we have got to change in our strategy - allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company.

        We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

        Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows.

        I would be glad to explain at a greater length.

        Likewise this love of DAV in Office/Exchange is a huge problem. I would also like to make sure people understand this as well.

        -----------


        Clearly the word is getting out about the problems in OOXML. Stéphane Rodriguez notes at the bottom of OOXML - Defective by design:

        Update : this article was Slashdotted on Sunday 26 of August.

        Update2 : this article is taking 300,000 hits a day, and is making it all around the world in all kinds of sites. My web host provider was so angry at the peak in traffic that he threatened to cut me off, so I had to redirect to a blog site such as Google's blogger to host the article.

        Update3 : wednesday august 29, added a new section on Document security

        Update4 : friday august 31, added more content to sections US English and Windows dates

        Update5 : sunday september 2, added a quick comparison between ODF and ECMA 376

        • Stéphane Rodriguez lost all credibility when he edited an OOXML spreadsheet file by hand, changed the XML so that it was no longer legal according to the schema, and then proclaimed that it was a flaw in OOXML that Excel found an error in the document.

          • Stéphane Rodriguez lost all credibility when he edited an OOXML spreadsheet file by hand, changed the XML so that it was no longer legal according to the schema, and then proclaimed that it was a flaw in OOXML that Excel found an error in the document.

            Brilliant piece of misrepresenting an experiment made to illustrate a point, then dismissing everything this man has said. Congratulations on your rhetoric! Or perhaps you aren't that brilliant, and simply did not understand the article. For those who

            • Incorrect. All that was required for the update he wanted to do was either (1) updating two locations, not one, or (2) removing one file. The spreadsheet file stores some extra information as an optimization to allow spreadsheets to load faster (basically, information on calculation chains).

              Here is a thorough point-by-point response [slashdot.org] to Rodriguez's points.

              BTW, it is interesting to note the comments when this was discussed [msdn.com] on Brian Jones' blog. Note that he lets Rodriguez comment, even though Rodriguez

              • We know about you and your buddy Miguel. What's your agenda, you guys - anyhow? Your support for Microsoft flies in the face of all logic. You think this world will somehow be a better place when there is only One Microsoft Way? - for document formats, on the desktop, on the Net? I'm not going to take the bait, and I don't have the detailed knowledge to rebut this. Nor will I call you a Microsoft shill or a troll. I don't know who you are, and for all I know, if I met you, maybe I would like you. You are we
      • Heck, isn't just about everything stored in ISO 8859? I actually thought it was the same as ASCII until reading this: http://kb.iu.edu/data/ahfr.html [iu.edu].

        There's your ISO right there! Oh, format ... right ...

        • Re: (Score:2)

          by Fred_A ( 10934 )

          Heck, isn't just about everything stored in ISO 8859? I actually thought it was the same as ASCII until reading this: http://kb.iu.edu/data/ahfr.html [iu.edu].

          FWIW the 8859 section of that page is in bad need of an upgrade (the tables go beyond 8858-8, for example western Europe uses 8859-15 which adds € and completes character tables that were left unfinished in -1)...
          You might want to check Wikipedia which appears to be much more complete (for once).

    • Let's not look a gift horse in the mouth. If MSFT had corrected the flaws, they'd probably be able to crowbar their 'standard' through the relevant hoops.

      As it is, a true, open, unencumbered standard will instead prevail.

      • Re:Office 2007 (Score:5, Insightful)

        by peragrin ( 659227 ) on Wednesday March 19, 2008 @02:26PM (#22798172)
        If MSFT fixed the flaws with OOXML then there wouldn't be a problem.

        it's not that OOXML is bad, it is that OOXML is broken and MSFT is trying to ram it through anyways. there is nothing there that can't be fixed. MSFT however doesn't want it fixed because OOXML 2010 is just around the corner and it won't be the same as OOXML 2007. Also OOXML 2010 becomes a defaco standard even though it isn't ISO certified since it is marketed as OOXML.

        this is how MSFT works if you don't know this then go back and look at the past 30 years of how MSFT treats it's customers, vendors, and slaves.

        • If MSFT fixed the flaws with OOXML then there wouldn't be a problem.

          Pop quiz, hot shot! Reconcile your statement above with your statement below.

          this is how MSFT works if you don't know this then go back and look at the past 30 years of how MSFT treats it's customers, vendors, and slaves.

          For bonus points, explain how what you say is a reply to my post.

          Standards need to be open, unencumbered by patents, and as easy to implement by third parties as they are by the originators. MSFT has failed in these basic

        • it's not that OOXML is bad, it is that OOXML is broken and MSFT is trying to ram it through anyways

          I'm not sure how Microsoft is trying to "ram it through" - Microsoft are following the ISO process for standards that are developed externally (i.e. not developed inside ISO). That process is called fast track, and it's how ISO deals with "existing" standards.

    • Re:Office 2007 (Score:5, Insightful)

      by Basilius ( 184226 ) on Wednesday March 19, 2008 @01:56PM (#22797848)
      There are no existing implementations of the proposed OOXML standard, so whether Office 2007 has the same defects or not is sort of irrelevant. MSFT has stated that they will not be implementing the standard as proposed, but will be going a different direction. And, given the nature of parts of the standard, nobody BUT Microsoft can fully implement it.

      The mere fact that there ARE no implementations of OOXML, however, should be a giant, florescent, waving red flag. No standards body should adopt a standard that cannot and will not be implemented by the proposers.

    • Re: (Score:2)

      by flymolo ( 28723 )
      Some of these are flaws in the specification. Like not explaining ranges or the description of a field being a URL, but the type any string. It comes down to the spec was written post hoc, and Office 2007 probably isn't run through a spec compliance test suite.

      The database connection flaw may not be in Office either, because Office may force System DSNs rather than real connection strings.

    • Re: (Score:3, Insightful)

      by UnknowingFool ( 672806 )
      As far as I know even Office 2007 can't do OOXML well.

  • huh? (Score:5, Interesting)

    by trybywrench ( 584843 ) on Wednesday March 19, 2008 @01:50PM (#22797764)
    This may be off topic but why exactly are there database connection strings in a document format?

    • Re:huh? (Score:5, Informative)

      by Shados ( 741919 ) on Wednesday March 19, 2008 @01:57PM (#22797858)
      Because people actually do work with Office Suites, and they are an integral part of the workflow and ecosystem of significant companies IT.

      For example, a spreadsheet is often the favored client for an OLAP system, and complex spreadsheets will get reused a lot, so connection strings may be part of the overall "application" that the document has become.

      People like me and (probably) you tend to use documents as just that: documents. But in the big boy's world, they're far more important than that.

      • Re: (Score:3, Informative)

        by RobBebop ( 947356 )

        But in the big boy's world, they're far more important than that.

        I acknowledge that hooking documents into databases to subvert them into workflow process template beasties is a common practice, but I think the simple question "Why are there database passwords in the document?" kind of highlights that this is a bad practice.

        If security is a concern, "Document Applications" are a mistake.

        This also violates the (good) Model/View/Controller [wikipedia.org] software architectural model by kludging the view and controller together in the same product. And - despite claims that it cuts

        • This also violates the (good) Model/View/Controller software architectural model by kludging the view and controller together in the same product.

          No, not really. Think a simple mailmerge with data from the database. There is no Controller, only a model (the DB) and the View (the document). You fetch the data from the database and mailmerge it.

          • Re: (Score:3, Interesting)

            by RobBebop ( 947356 )

            This also violates the (good) Model/View/Controller software architectural model by kludging the view and controller together in the same product.

            No, not really. Think a simple mailmerge with data from the database. There is no Controller, only a model (the DB) and the View (the document). You fetch the data from the database and mailmerge it.

            Yes, I have read that a compelling reason to stick to Microsoft Office is the ability to Mailmerge, which is fine. I have never gone through the hoops to perform a Mailmerge, so bare with me. My belief is that the whole purpose to send the date (in the database) through the document (which is the controller) to a printer (where it can be viewed). This simple/trivial application actually does separate Data/View/Controller.

            Saying there is no controller is like saying there is no spoon. Just because it

          • Re: (Score:2)

            by AJWM ( 19027 )
            There is no Controller, only a model (the DB) and the View (the document). You fetch the data from the database and mailmerge it.

            Who or what is "you" in this case? That's the Controller. Something has to control which data is selected from the model and how it is viewed. There's always a controller, but sometimes it's horribly intertwined with one or both of the other parts.
            • I think we are really getting philosophical here, but there is no controller. You (the office document) fetch the data from the DB. So, office document = view and DB = model. There is no controller. The definition of controller I have is: "Processes and responds to events, typically user actions, and may invoke changes on the model." - The office document does not do that. It only displays the data.

              • Re: (Score:2)

                by dkf ( 304284 )

                I think we are really getting philosophical here, but there is no controller. You (the office document) fetch the data from the DB. So, office document = view and DB = model. There is no controller. The definition of controller I have is: "Processes and responds to events, typically user actions, and may invoke changes on the model." - The office document does not do that. It only displays the data.

                I disagree. There's a Controller. It's the trivial default one implemented by the viewing application. (Of course, it only really gets interesting when you start pushing changes in the document back at the database; that's when you start to build a controller of substance...)

        • Re: (Score:2)

          by Tony ( 765 )
          This also brings up two other problems with the practice of document-applications: islands of data, and programming errors.

          I have seen more programming errors in spreadsheets being used a database management systems than in any other code. And I don't know how many times I've seen the exact same analysis being done by two different secretaries (in the same office!) using spreadsheets they wrote themselves. Each of them. Separately. "Oh, it only took me a couple of weeks."

          I think calling it the "big-boys wor

        • Re: (Score:2)

          by Shados ( 741919 )
          WTF does MVC have to do with it? There are douzans of UI design patterns. MVC Type 2 (the one you're thinking of) is a popular one, especially because of the like of Struts and Rails, but the vast majority of (even well designed) apps don't follow it... There's so many other good ones. MVC Type 2 is just a freagin design pattern, and a semi-obsolete one at that (that people follow semi-blindly because its been around for so long), its not the holy grail of software architecture model (its not even one!)

          That
      • For example, a spreadsheet is often the favored client for an OLAP system, and complex spreadsheets will get reused a lot, so connection strings may be part of the overall "application" that the document has become.

        I guess so but i figured the document itself would name the data resources it needs and it would be up to the application to actually connect and retrieve the data. I wonder if the document itself can initiate a connection and execute a command. It basically does a "select" to pull data in, c

    • Re: (Score:3, Informative)

      by jfclavette ( 961511 )
      They're there for data bindings to databases, which can be used for anything from mass mailing clients to generate a list of items with pricing.

      I'd be interested in what is the alternative to storing them in plaintext in the document format. See, the database is going to be wanting that password, and it must be stored somewhere in the document in a stand-alone way or remembered by the user. If you encrypt it, you need to provide the keys in the same document or use a constant well-known key across all ins

      • Re: (Score:2)

        by Ed Avis ( 5917 )
        +1

        It is not a security flaw to store passwords in plain text - or at least, 'encrypting' them with some fixed algorithm gives no security benefit. At best it's security through obscurity.

        In fact, it's surprisingly sensible of Microsoft to recognize this, given the 'compressible encryption' and other non-security security nonsense they provide in other products.
      • I think you're missing something important. The document format should not store this information at all -- it's the job of the keyring password manager. The document may define an alias for the database connection string, but it shouldn't provide the actual connection details since that would be a security hole.

        Look at it from another angle. Imagine that I need to connect to the database using the connection string, a@mycompany.com:mypass. I send you the document, but you're on another network. You don't s
        • Not a bad idea but now you need to graft a standard interface to a keyring password manager in the standard. Is it worth it ? Like has been mentionned in other posts, it is very possible to attain more security trough relying on Kerberos or Active Directory for authentication and that's trivially implemented with a custom connection string. My point is merely that I consider it a 'less secure but more practical option for the little guy', not a security vulnerability. It's a viable option when your data

      • I'd be interested in what is the alternative to storing them in plaintext in the document format.

        We use Kerberos to authenticate the user with the database, and something like Row Level Security or/and Database Roles for authorization on the actual data. That's actually the only secure way I know of (and that I use) to connect to a database from an office document.

        • Re: (Score:2)

          by Rich0 ( 548339 )
          I think it depends on your needs. If the access is read-only and the data isn't sensitive then the embedded string isn't a problem.

          I'd say that in my experience users actually having accounts on database servers is pretty uncommon. Most applications just connect to the database using an obfuscated password, or they have a business-logic tier that does the data manipulation.

          I agree completely that single-user database accounts are far more secure, but they can be a lot more difficult to maintain and as a r

          • I'd say that in my experience users actually having accounts on database servers is pretty uncommon.

            I agree. Usually users in an enterprice are stored on an LDAP server.

            Most applications just connect to the database using an obfuscated password, or they have a business-logic tier that does the data manipulation.

            That's also true, but in a sane environment you have your users/accounts on an LDAP server and Authenticate them against it (usually with Kerberos tickets).

            ctrl+c ctrl+v from Oracle Security and Iden

    • Just in case you need to pull data from database to calculate some data in your document (for example presentation which shows a list of current clients, not list of clients available at the moment of making this presentation).

  • enough is enough (Score:5, Interesting)

    by BroadbandBradley ( 237267 ) on Wednesday March 19, 2008 @02:01PM (#22797900) Homepage
    how long will it take people to shrug off this death grip of MS and realize that it's costing billions in productivity? I received an XLS file of contacts yesterday and I figured I'd try using Outlook to import it into an address book so I could then sync to other things like Gmail. Outlook choked and recommended assigning values to the columns using another MS product - MS Excel. SO, I saved the file as CSV, and imported using Thunderbird which gave me an easy dialog to match up name,email, phone, website..and so on. Worked great! then I used thunderbird to open the second file and it remembered the previous adjustments and everything was already lined up! Awesome stuff and I wasn't prompted to buy any other products!

    I'm seriously considering wiping all the PC's in my office and advising the staff to just learn Ubuntu to avoid this whole MS deathgrip. None of the staff are advanced users except my web guy who codes in a text editor anyhow. FMS.

  • What's the point? Who is going to follow this? (Score:4, Insightful)

    by pembo13 ( 770295 ) on Wednesday March 19, 2008 @02:05PM (#22797960) Homepage
    As I understand it, Microsoft isn't going to follow this standard. If Microsoft isn't going to follow this standard, then it is useless for OpenOffice, NeoOffice, KOffice, etc. to follow this standard. Or is this going to be for Office 2k10 or something?

    • Re:What's the point? Who is going to follow this? (Score:5, Insightful)

      by MLCT ( 1148749 ) on Wednesday March 19, 2008 @03:04PM (#22798590)
      MS doesn't care about anyone following it (since even they themselves aren't going to). All they are doing it for is so they can claim that MS Office uses an open ISO standard, OOXML (even though it won't use the ISO passed standard) so that governments, businesses and buyers are not scared away from their products.

      As with everything MS does it is all about control and money. They have observed the fights that took/are taking place at various governmental and state levels over the mandatory use of an open standard - and they see that it is a threat to their monopoly, hence they have strategised to nullify the problem without giving up any of their control. The whole thing is a rate 10 sham. And if anyone ever wants to know why a lot of people don't trust MS then this is a perfect example of it - the process and the mockery they are making of it is frankly satirical.

      • Re:What's the point? Who is going to follow this? (Score:4, Interesting)

        by johannesg ( 664142 ) on Wednesday March 19, 2008 @05:25PM (#22800270)
        You are absolutely spot on, and what's worse, we can also confidently predict the next step: governments and organisations will be falling over themselves to proclaim their support for OOXML, since it is "an ISO standard". Then they will happily sign their soul over to Microsoft because they have a product that implements this standard, while at the same time disallowing OpenOffice and other office packets because they are not fully compatible with MS Office.

        Then we will tell them that Microsoft is actually not implementing their own damn standard correctly, and we will be laughed away - after all, Microsoft *IS* the standard, so how could it be incorrect?

        And it will all be business as usual...

        The whole thing makes me intensely sad. By the way, we had some articles about the Dutch government requiring open formats a while ago. I professed severe scepticism at the time. Let me give you a little update on that one, then: as it is, the new desktops are required to support a very wide range of technologies that can ONLY be fullfilled by having MS Office on MS Windows. So although the government requires open standards, it also requires Active Directory, for example. And guess what they are buying? Yes, that's right: MS Office on MS Windows. But, we are told, in the next round (in 2011 or so), there will definitely be an opportunity for Linux "because in this round we are already ensuring compatibility".

        As I said, business as usual.

    • As I understand it, Microsoft isn't going to follow this standard

      They've explicitly committed to supporting it in whatever form it is in if/when ISO approves it.

    • Re: (Score:2)

      by tsa ( 15680 )
      I heard somewhere Apple is working on an implementation of OOXML for their office suite.

  • So he wants security through obscurity... (Score:3, Insightful)

    by Rakishi ( 759894 ) on Wednesday March 19, 2008 @02:11PM (#22798018)

    Even so, he's found a number of new flaws, including a security vulnerability: OOXML stores passwords in database connection strings in plain text.
    And how will the format magically produce the plain text password again when the database asks for it... oh wait it can't unless it's easily recoverable in plain text form. It's also not like the "encryption" mechanism would be documented and it's not like someone would have to read that very documentation to know even where the password is stored... oh wait.

    Anyone who claims that it's more secure to obscure the password in a well known and trivially reversible way instead of simply storing it in plain text is not someone I trust to analyze security.
    • It adds complexity, which is generally bad for security, and makes the format harder to understand, which is also bad.

      The word that comes to mind is "dumbass".

      I do hope there is an option to have an "ask the user" password. (not stored in file)

    • Re: (Score:2)

      by tigre ( 178245 )
      The one thing it does help prevent is accidental disclosure of passwords. If the contents of the file are exposed, but not the key to unobfuscating the contents, then there is a significant security benefit.
    • You're putting words in his mouth. He never recommended obfuscation as a "fix" for this issue, now did he? That was YOUR idea.

      Personally, I would require the user to supply the password, or else I would create something where the document was signed cryptographically and presented itself to the database for authentication. I'm sure there are other, better ways of doing this than just "who cares? store it in plain text because we're lazy and don't care!"

      • Re: (Score:2)

        by Rakishi ( 759894 )
        None of your "solutions" preserve the functionality that the current proposal has. One requires not only user input but the need to send this second password to the user, in some cases not a trivial possibility. The second requires a special database setup and won't work in the majority of cases. Sure other methods can also be included but those are new features and the plain text one will still be left there.
    • Here's the encrypted key to one of my documents. It is stored in the document itself:

      $2$gJT/A1qk$CyM4Z4UleBaoMyruOx9Ku

      Now you may start to guess what pass phrase to use to recover the plain text. Have fun...
      • If an "encrypted" key is stored in the document, then the format itself must be reversed by the local bits on the machine using a standardized algorithm, correct? Otherwise, the document isn't interoperable. So, you've just given out your password, with the only difference being that now it probably takes someone more work to uncover the passphrase. Worse, users are likely under the impression that the key is actually secure.

        Oh, and your passphrase is:

        $2$gJT/A1qk$CyM4Z4UleBaoMyruOx9Ku
        I don't understand s
    • Nice straw man. Of course, if a password was simply "obscured" in a "well known and trivially reversible way", then yes, gosh, that wouldn't provide any protection at all.

      But Rob Weir didn't make that claim. He just pointed out that plain text passwords were being stored in the document format, and that this is a security risk - which it is. It may be fine in some circumstances - but in all the other ones, where it isn't fine, there is no other mechanism provided by the standard.

      Now, if a password were to

    • Putting the password in the document file in any form is the problem.

      A car analogy is obviously called for. The OOXML standard describes a method for taping your car keys to the driver's side window where your co-worker can easily find them when he wants to take your car for a spin.

      There are secure methods of managing passwords, especially in an "Office Suite" environment, but none of these are in MS' bag of tricks.

    • You're missing the point, really..

      There should be *NO* passwords in documents. Period. What you should do is make personalized user accounts in the database for all users that actually require access to this data, then have that username automatically filled in from the logged on user, then prompt the user to type in their own password.

      This provides a solid authentication model, will deny all users who have nothing to do with this data to access it, and will also create a personal audit trail.

      ps. This is my

  • Implement first, standardize later. (Score:3, Insightful)

    by colmore ( 56499 ) on Wednesday March 19, 2008 @02:28PM (#22798196) Journal
    Did we learn nothing from the 80s and early 90s? If you write the standard first, you're going to get the kitchen sink. Engineer a good system, then standardize it. Nothing sands the sharp edges like the real world.

  • MSOOXML is not standard quality (Score:2, Insightful)

    by Anonymous Coward
    During the BRM is has been shown that MSOOXML is not up to the quality for an international standard.

    The only reason that this thing is considered in ISO is because Microsoft is being so bullish, trying to defend the monopoly.

  • Standards are not religons (Score:3, Insightful)

    by surfingmarmot ( 858550 ) on Wednesday March 19, 2008 @02:42PM (#22798342)
    Yet a lot of people treat them that way like this Slash Dot commenter: "He might well be right, but I'd be more inclined to believe it from someone who doesn't have a corporate interest in picking data points to fit the line he would like to draw." Just why is that rated a 5? It is NOT about belief, but more about science--either the facts and peer review support Mr. Weir or they don't. Apparently they do and in Spades. The majority of "yes" votes on this "standard" are by Microsoft partners who have a vested interest in a dingle vendor, single application (the only full implementation read and write) solution they sell products and services for and can lock in business. Sure IBM is a commercial organization with a checkered past, but they don't own completely open ODF so they aren't doing this for gain. they jsut want a level playing field for formats. And it is a great idea.
  • OOXML's Flaws Have Been Addressed

    "IBM's Rob Weir has done a study on how many flaws were addressed by the OOXML Ballot Resolution Meeting. So far, using a random sampling technique, he has yet to find a flaw [...] there were no mistakes on [...] the [...] pages he reviewed."

    There. Doesn't that sound better? :-)

  • OOXML stores passwords in database connection strings in plain text.

    Am I the only person who's wondering WTF a database connection string is doing in a word processing document?

    I'm starting to understand why the spec is 6000 pages long.

  • How the hell would YOU store passwords? With an encrypted text using a fixed key? Or with a randomly generated key stored in the file (key union ciphertext == plaintext)? Or maybe use an NTLMv2 hash that connects ONLY to a proprietary database (MSSQL) with a proprietary setting, which you can happily replay (we call this a secondary password...)? The only solution is to password-lock the file and use the password to encrypt a master key that encrypts A) the whole file; or B) a master password list embed
    • If the doc requires a connection to a database, surely requiring a connection to a standard authentication mechanism (kind of like how firefox does it if you assign a master password for your stored passwords). Yes, a PITA, and maybe silly, but no more so than allowing a word processor document to connect to a database in the first place.
      • Yes, but then the auth mechanism would require all kinds of things, an encryption key for each user, etc.. it's a hard problem.

  • OOXML approved by NIST (Score:3, Informative)

    by seandiggity ( 992657 ) on Wednesday March 19, 2008 @04:00PM (#22799188) Homepage
    Even though none of the substantial problems have been addressed, NIST has approved OOXML [nist.gov].
  • As well as with the original article. First thing - you can't really say "few flaws have been fixed" when the original article (and the post blurb) specifically say that no fixed flaws where actually found in the testing sample.

    On the other hand, the statistics used by Rob Weir are shoddy according to my local statistics semi-expert (my girlfriend who finished 2nd year BA stats A. with a perfect 100 score). Specifically his sample is incredibly small: 25 random pages out of a random selection of 200 pages o

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close