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:[email protected]]
*Sent:* 08 April 2019 23:40
*To:* [email protected]
*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 <[email protected]>
*Sent:* Monday, April 8, 2019 2:29 PM
*To:* [email protected]
*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 <[email protected] <mailto:[email protected]>>
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 <[email protected] <mailto:[email protected]>>
Mike Cantwell <[email protected] <mailto:[email protected]>>
For policy questions, send mail to:
Jim Bacher <[email protected] <mailto:[email protected]>>
David Heald <[email protected] <mailto:[email protected]>>
-
----------------------------------------------------------------
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 <[email protected] <mailto:[email protected]>>
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 <[email protected] <mailto:[email protected]>>
Mike Cantwell <[email protected] <mailto:[email protected]>>
For policy questions, send mail to:
Jim Bacher <[email protected] <mailto:[email protected]>>
David Heald <[email protected] <mailto:[email protected]>>
-
----------------------------------------------------------------
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 <[email protected]>
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 <[email protected]>
Mike Cantwell <[email protected]>
For policy questions, send mail to:
Jim Bacher: <[email protected]>
David Heald: <[email protected]>
