Yes, that might the point of fitting such screws, but the standard would then have to define both such screws and the specific assessments/tests that would be necessary for them to be deemed acceptable/certifiable - but, of course, it actually says nothing about either of those matters.
John E Allen W. London, UK From: John Woodgate [mailto:j...@woodjohn.uk] Sent: 09 April 2019 16:01 To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Tamper-proof Hardware Yes, that is clearly the point of fitting t-p screws. Best wishes John Woodgate OOO-Own Opinions Only J M Woodgate and Associates www.woodjohn.uk Rayleigh, Essex UK On 2019-04-09 15:56, Larry Merchell wrote: Per: 3 to engage secretly or improperly in something. Wouldn't improperly be the key word, as it may expose a hazard? Larry Merchell _____ From: John Woodgate <mailto:j...@woodjohn.uk> <j...@woodjohn.uk> Sent: Tuesday, April 9, 2019 2:36:47 AM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Tamper-proof Hardware We are not so far apart. You say that the text should not have appeared in a numbered clause that might be assumed to be normative. I say that it would be better not to have a numbered clause because it might seem to be normative. I think that few would assume that the normal INTRODUCTION text in an IEC standard is normative. See 13.2 of Directives Part 2. Best wishes John Woodgate OOO-Own Opinions Only J M Woodgate and Associates www.woodjohn.uk Rayleigh, Essex UK On 2019-04-09 10:28, John Allen wrote: John W When something that ambiguous, and which that could be construed as being a requirement, is placed in a prominent position in a standard, regardless or not of whether the clause in question is numbered, then it is obvious that it will (as it has done) raise issues and questions as to the potential effects on many other parts of that standard . BTW: it has been widely and authoritatively stated that 62368 is not a "Risk Assessment" standard, and appropriate rationales and requirements are thus given therein - but to then include an undefined term which might then be construed as a "requirement" is an open invitation for someone to decide that "he" has to risk assess how "tamper-proof" a particular design safety feature actually might be. Those are some of the reasons why I consider that the term in question should never have been included in the first place. John E Allen W. London, UK From: John Woodgate [mailto:j...@woodjohn.uk] Sent: 09 April 2019 09:40 To: John Allen; EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Tamper-proof Hardware I think that the major point is that Clause 0 is purely advisory. It seems reasonable in an advisory text to mention means to deter operations that might compromise safety, without going into exhaustive detail. It would seem harmless, so not worthy of suppression. I wouldn't have given the INTRODUCTION a clause number, because it creates an impression that it is normative. But then there are 10^6 things in 62368-1 that I would have done differently. Best wishes John Woodgate OOO-Own Opinions Only J M Woodgate and Associates www.woodjohn.uk Rayleigh, Essex UK On 2019-04-09 09:11, John Allen wrote: Rich Thanks for laying out the main definitions of "tamperproof", and for your view on why my "story" is not an example thereof (it was only the one that I had "to-hand" at the time, and there must be many others J) . Maybe, therefore, similar definitions/explanations should have been included in IEC 62368, so as to make it (much!) clearer to designers and testing/certification personnel as to the intent of the requirement because (obviously) there can be a considerable spread of interpretations of the requirement - or else John Cochran (and probably many others!) would not ask the question. As it stands, that "requirement" must thus be considered to be "ambiguous" at best, and therefore shouldn't have been included in a standard in that form (I'm sure there must be a word to describe a definition with four different possible interpretations, but I'm afraid I don't know it and thus "ambiguous" is the best that I can offer ATM!). In fact, given the definitions you quote, I would suggest that the term should NOT have been included in the standard at all because they imply the likelihood of various levels of intentional interference/criminality on the parts of possible perpetrators. However, it should not have been the intent of the 62368 standards-writing teams to address such issues - maybe YES if it were in a theft/ building-intrusion/ forgery prevention (etc.) standard, but NO in a broadly-targeted product safety standard. John E Allen W. London, UK From: Richard Nute [mailto:ri...@ieee.org] Sent: 08 April 2019 23:40 To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Tamper-proof Hardware >From dictionary.com: tamperproof adjective 1 that cannot be tampered with; impervious to tampering tamper verb (used without object) 1 to meddle, especially for the purpose of altering, damaging, or misusing (usually followed by with ) 2 to make changes in something, especially in order to falsify (usually followed by with ) 3 to engage secretly or improperly in something. 4 to engage in underhand or corrupt dealings, especially in order to influence improperly (usually followed by with ) The example provided by John Allen (UK) is not tampering as he did not take the unit apart for any of the above reasons. Using the above definitions, the reasons for using any "tamperproof" construction assumes nefarious objectives on the part of the equipment users. Best regards, Rich From: John Allen <mailto:000009cc677f395b-dmarc-requ...@listserv.ieee.org> <000009cc677f395b-dmarc-requ...@listserv.ieee.org> Sent: Monday, April 8, 2019 2:29 PM To: EMC-PSTC@LISTSERV.IEEE.ORG Subject: Re: [PSES] Tamper-proof Hardware IMHO, the subject of "tamper-proofing devices" will be around for a "long time" because, once a "new" device is introduced, then "someone" will (pretty soon!) come up with a "workaround" - it's just a case of when the workaround becomes available, and then when will someone find and use it, and NOT if they will! L By way of example, today I finally looked to see if I could fix an old non-functional plug-in mains-supplied timer, but then found that the 2 parts of the body were secured by "tamper-proof" screws, which were roughly like a normal flat-blade screw head, but with a gap in the centre for a spigot on the end of the removal tool - which I have had in the toolbox for, probably, nearly a decade! Thus I had the timer apart in a few minutes (and then found the cause of the problem quite quickly). Thus it's a matter of "not if", but "when". OTOH, to "come down to ground" - in practice, it all comes down to the question as to whether the "intended users" are likely to be able to find the workaround, and would then want to, bypass the safety measures ?????? John E Allen W. London, UK - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) <http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher <j.bac...@ieee.org> David Heald <dhe...@gmail.com> - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) <http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher <j.bac...@ieee.org> David Heald <dhe...@gmail.com> - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) <http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher <j.bac...@ieee.org> David Heald <dhe...@gmail.com> - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) <http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher <j.bac...@ieee.org> David Heald <dhe...@gmail.com> - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) <http://www.ieee-pses.org/list.html> List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher <j.bac...@ieee.org> David Heald <dhe...@gmail.com> - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <sdoug...@ieee.org> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher: <j.bac...@ieee.org> David Heald: <dhe...@gmail.com>
