, 104 tweets, 86 min read Read on Twitter
The @BBFC #AgeVerification "Certificate Standard" has been published.

This is the document which is being proffered to protect the facts & details of _YOUR_ online #Porn viewing. Let's read it together!

What could possibly go wrong?

@BBFC Well, that was fast:

"this is the foundation of the non-statutory, voluntary age-verification certification scheme (the Scheme)"

"Only age-verification providers that meet the requirements of the Standard…will receive certification"

What happens to the ones that don't?
@BBFC [ Incidentally, I am going through this in real time with a mug of coffee, so there may be some jumping back and forth. Don't expect perfection. ]
@BBFC The word "voluntary" appears 3x on page 3 and nowhere else, apparently.
@BBFC Elsewhere I have noted the fact that porn-browsing metadata is clearly data which "concerns a person's sex life or sexual orientation" per the DPA, which ranks it for "sensitive processing".

In case I miss it, let me know if they've got this covered?

@BBFC In any case, the notion that a voluntary scheme is adequate for "sensitive processing", whereas my favoured PCI/DSS is likewise "voluntary" … but if you miss the PCI/DSS bar, you can't receive money.

Bit of a difference, there.
@BBFC There is a clear opportunity for protecting the British public from #cyber risk, here: the parental-control filters which are proposed for blocking websites that do not do #AgeVerification, can also be used to selectively filter non-certified sites.
Why would @BBFC permit people to access websites which fail to meet their information security standards?

How is that ethical of them? Do they want to put people in harm's way?
@BBFC Lee notes below that this could be "flying a kite" / actually intended as a step towards a mandatory scheme for regulating the internet; but that's not what we were sold, & if the Gov't want to do that, they should have framed it that way to start with.

@BBFC OMG, this is very clever, but it is utterly terrible for the threat model.

Don't get me wrong - this is the laudable ISO27001 & BSI approach towards security, but what they _actually_ ought to be doing is the PCI/DSS approach towards security.

Explanation coming up:
@BBFC There are two (?) kinds of "information security standard" - in truth you need BOTH but in varying proportion, depending on need.
One is the "write your own specification, and then prove you meet it" kind; this "ISO27001" kind of standard exists to assure people that you've actually bothered to think about what you are doing, that you're not being slapdash.

This is what's being proposed. It's not enough.
The other is the "you live in an earthquake zone, you must build your buildings to cope with these kinds of environmental hazards, bridges not collapse, and not kill people"-kind of standard.

Such is the PCI/DSS approach: "the Internet is an information security earthquake zone"
The challenge with PCI/DSS ("building in an earthquake zone") -type security standards, is that they tend to be thick and filled with *hard* rules about material and design specifications.

This takes time, and the @BBFC have not _got_ time, so they have attempted to bodge it:
@BBFC What they've essentially decided, is:

«We can't build an earthquake-proof information security spec in time, so we'll let people build whatever they want, require them to document it fully, and then we'll go shake the buildings every so often to see if anything bad happens?…»
@BBFC This kind of "shake-the-building" approach is called #PenetrationTesting, and — possibly most terrifying of all — the @BBFC standard somehow manages to handwave over ALL the detail of doing this ("…industry recognised methodologies…") in a SINGLE page of the document:
@BBFC [ off to refill coffee; while I do that, consider for yourself whether, if you lived in Tokyo, you would want to live in a building designed and blueprinted by amateurs, but where they crashed cars into it occasionally to see if it is "safe enough" ? ]


@BBFC [ incidentally, this morning's coffee is a Kenya Kieni AA Washed from @hasbean ]

@BBFC @hasbean …AAAAAAAND we're back; but, wait, what?

I was on page 4 where I was talking about how the "Objective" was a shallow bodge upon ISO27001-style self certification, by pairing it with a pentest in order to attempt to bring some rigour and integrity to the vendor's defences:
@BBFC @hasbean AND THEN… I skipped ahead to the "pentesting", because clearly if they are hanging so much faith upon "…but there was a pentest!" then that must surely be a huge section!

Yet it was only a bit less than a single page:
@BBFC @hasbean THEN I FOUND… that it was actually the _next_ page; like: "§4 Objective" on Page 4, and "§7 Penetration Testing" on Page 5.

Wait, what? Like, shouldn't there be tons of substance in that gap? This is an 18 page document, after all…
@BBFC @hasbean So: what is in the gap? "Principles & Definitions" — or, as I like to think of them, "get out of jail, free"-clauses.

This is all about how to blame someone else / say "it's not _our_ fault", when someone commits suicide after a data leak:
@BBFC @hasbean The "Principles" appear to be simple assertions that this is all right, just, proper, secure, and commensurate with building a vibrant ecosystem of diverse #AgeVerification solution technologies.

In truth, they're window-dressing.
@BBFC @hasbean "Data Protection" - by reasserting the DPA, they are claiming compliance with the DPA / GDPR as a standard, which I aver is wrong on the face of it, but shouting "LA-LA-LA-LA-I-CAN'T-HEAR-YOU" has always been a popular tactic:
@BBFC @hasbean "Flexibility" and "Selection" are sops towards why the @BBFC feel they cannot be prescriptive regards protecting peoples' #ageVerification data - "because there's simply too much 'white heat of technology' out there, going on, for us to lay down any rules."

That's bullshit.
@BBFC @hasbean …and "Security"?

"the Standard will ensure the appropriate technical and organisational measures shall be in place to ensure the confidentiality, integrity and availability of age-verification solutions"

@BBFC @hasbean [ at this point, I would like to apologise to @hasbean who are now inextricably looped into this thread, and Twitter have removed the means for me to expunge them from it; this is a matter for regret. feel free to mute the thread, folks. ]
@BBFC @hasbean "the Standard will ensure the appropriate technical and organisational measures …to ensure the confidentiality, integrity and availability of age-verification solutions"

Will it? Fuck me, no. It punts everything technical to vague obligations upon the #AgeVerification provider:
@BBFC @hasbean Most of section 8 can be rewritten as:

"For each <sensitive thing> you will promise to <treat it sensibly, at very least write-down that you have got it, so that people remember>".
@BBFC @hasbean There is NOTHING in this document along the lines of "you are attempting to build a new service handling VERY SENSITIVE DATA in an exceptionally hostile environment, what you build must exceed at least <these requirements> in order to permitted to operate."
@BBFC @hasbean It's yet another massive irony, really, that this is all in pursuit of #AgeVerification, but nobody is putting a sign in front of the Age Verification companies saying "YOU MUST BE AT LEAST THIS TALL TO RIDE" tvtropes.org/pmwiki/pmwiki.…
@BBFC @hasbean Though it's nice that @BBFC reminds companies — THOSE WHO BOTHER TO VOLUNTEER TO SIGN UP FOR THIS —that:

«Users shall be notified of changes to how the age-verification provider processes personal data for the purpose of age-verification.»

…since it's a legal obligation anyway
@BBFC @hasbean Also, from my perspective as someone who does security as a living, it's hilarious that §8.1.10 is meant to coerce companies into stopping automated AV bypass … but it actually also means "if your site gets scraped for porn (or deep-linked to images?) you're non-compliant".
@BBFC @hasbean «The age-verification service shall include measures which are effective at preventing use by non-human operators including challenge–response tests and algorithms»

— next stop: trying to make it illegal to inadequately prevent website scraping. "Walled-Gardens-R-Us", etc.
@BBFC @hasbean Perhaps the most galling thing in this document is §8.2 - BECAUSE IT'S ACTUALLY REALLY GOOD; that's because it is written about human security processes, and people generally have a better understanding of the risks of human-in-systems than they do of (eg:) "blockchain".
@BBFC @hasbean §8.2 and §8.3 have some really awesome security process in there; they state a requirement ("use passwords") they outline the minimum spec ("at least 15 characters") and they define edge cases ("not reuse commonly-known / breached")

"A risk management framework shall be implemented for the identification, assessment, ownership and management of information security and data protection risks."

@BBFC @hasbean There's some flaws in §8.3, and some matters of taste - why are "privileged" and "service" accounts equipped with 15 character passwords like ("Aaaaaaaaaaaaaaa1!") but "non-privileged" are only 8 characters?

What does non-privileged mean, anyway, for reals?
@BBFC @hasbean Amazing: §8.2 and §8.3 are really good, then you get into §8.4 and the rot sets in; starts well ("OMG they specified AntiMalware in §8.4.3, okay, so, that's pretty pointless on Linux but PCI does the same") …but then it just slides down into vague "X shall Y" senility again:
@BBFC @hasbean "Finally, the Encryption section! Something to get my teeth… wait, what? Hang on. This is it? Encryption is mentioned 4x in the document, + once in mobile device management, and that is ALL?

@BBFC @hasbean The entire @BBFC #AgeVerification security standard for encryption usage, for protecting data that pertains to a person's sexuality, checks in at 319 characters, slightly overflowing a single tweet:
@BBFC @hasbean [ this is crazy. i need to take a break from this for an hour or so. more, later. ]
@BBFC @hasbean So I got some shopping in, and have some chores to do, but whilst I get on with those, think about this: there's a bunch of folks on my feed saying, as we geeks are prone to do, "Just get a VPN".

That's a kludge, it's not a solution.
@BBFC @hasbean Partly because there's a bigger picture of how this will distort the porn-production & availability landscape, as neatly outlined here by @girlonthenet theguardian.com/commentisfree/…
@BBFC @hasbean @girlonthenet But also because of the chilling effect upon society and individuals, as (again) explained by @girlonthenet : girlonthenet.com/2016/10/17/get…
@BBFC @hasbean @girlonthenet The point is: in a free society with sensible approaches to education, and negating the concrete causes and impacts of harm rather than the purported mediums of it, we wouldn't be wasting time dealing with people who try to make life harder by enriching it with applied stupidity.
@BBFC @hasbean @girlonthenet —THE STORY SO FAR—

1/ the scheme is voluntary

2/ the scheme will be a hassle

3/ the scheme confers no customer benefit other than some kind of kitemark, which barely any customers will care about.

Ergo: the scheme is a fig-leaf for something
@BBFC @hasbean @girlonthenet Posit: imagine that an AV provider gets hacked-into ("popped")

- if they ARE NOT certified, they are roasted in the press / by regulators as presumably being slapdash/haphazard with process; this leads to "pressure to certify." Sounds good, yes? No…
@BBFC @hasbean @girlonthenet - if they ARE certified, it becomes a case of "we did everything we could, complied with all applicable standards, sorry that the patient died, not our fault…" — this toothless "standard" is a prophylactic against anyone — Gov't, @BBFC, the AV industry — being held responsible:
@BBFC @hasbean @girlonthenet There would be a small chance of the third-party penetration testers being held responsible for not finding the bugs leading to EVERYONE'S PORN-SURFING HISTORIES BEING LEAKED TO THE INTERNET — but that industry has long experience of avoiding liability.
@BBFC @hasbean @girlonthenet Clearly someone involved in this document has got actual experience of <some aspects of> security, because they got quite a lot of the human-risk elements down rather well. Albeit voluntarily.
@BBFC @hasbean @girlonthenet But any concrete security requirements — with a few exceptions, to follow — which touch upon actual digital security risks and mitigations, are kicked into the long grass of "shall be documented"
@BBFC @hasbean @girlonthenet Repeatedly there are assertions that something "SHALL BE" implemented (purple) but there is less often a DEFINED OUTCOME (blue) and the PURPOSES & MEANS (yellow) are vague:
@BBFC @hasbean @girlonthenet "Network diagrams shall be implemented and maintained to accurately represent the network topology. These shall be reviewed at least annually or after any significant change."

@BBFC @hasbean @girlonthenet On to §8.5 and "let's rephrase bits of the DPA to pad out the text a little" except:

"Data protection by design shall be implemented within all relevant business processes."

@BBFC @hasbean @girlonthenet "Only the minimum amount of personal data required to verify a user’s age shall be collected. A user’s identity shall not be verified as part of the process."

…ok, so how will the "fraud prevention and detection" stuff work? I believe this LITERALLY negates the point of AV.
@BBFC @hasbean @girlonthenet "Only industry standard pseudonymisation techniques and appropriate technical and organisational controls shall be implemented"

There are no standard pseudonymisation techniques; where deployed, pseudonymisation must be tuned to the information available in each environment.
@BBFC @hasbean @girlonthenet §8.5.8 is scary, saying:

"Age-verification providers shall only share the result of an age-verification check (pass or fail) with the requesting website."

But should say:

"…shall only share, AND SHARE ONLY the result of an age-verification check…with the requesting website."
@BBFC @hasbean @girlonthenet "Yeah, it's probably a bad idea for #AgeVerification providers to accrue a list of addresses and locations of all the kinky sexy people, especially the more vulnerable sorts… unless it's for fraud prevention and detection. That's fine."
@BBFC @hasbean @girlonthenet Oh, that's nice. Any #AgeVerification provider who volunteers to sign up for this scheme will have to provide a means of logged-out age-verification.

That means… session-ids / tracking cookies!

Otherwise the user experience will be far, far too painful.
@BBFC @hasbean @girlonthenet blah, blah, blah #gdpr
@BBFC @hasbean @girlonthenet Aside: nice point from Alexander, although the flipside is that location might be used to stop someone with stolen credit cards from signing up as <sockpuppet age-verified fake accounts> and selling them onwards.

@BBFC @hasbean @girlonthenet §8.6 Secure Development for #AgeVerification — Yay! This is my turf! This is where I have lived on/off for much of the past 30 years!

This is where… I get… disappointed.
@BBFC @hasbean @girlonthenet §8.6.1 — they could have just said "adopt the Microsoft SDLC" or something (which is a _security_ development lifecycle) and left less to chance. Plus, it presumes that the is a "lifecycle" at all; not guaranteed. microsoft.com/en-us/sdl
@BBFC @hasbean @girlonthenet §8.6.2 "Updates to software coding shall be tightly controlled and must be reviewed, approved and tested prior to release. All coding updates are to be approved by a change board or similar to ensure that the change does not having a negative or undesired impact."

@BBFC @hasbean @girlonthenet Coz then I read §8.6.5 "Code changes shall be reviewed by individuals who are appropriately trained and experienced" — and I am left wondering what §8.6.2's "updates to software coding", are?

Architecture? Implementation language? EBCDIC?
@BBFC @hasbean @girlonthenet Aside: there's a beautiful story in The Tao of Programming, dating from several millennia ago: mit.edu/~xela/tao.html

(see also en.wikipedia.org/wiki/The_Tao_o…)
@BBFC @hasbean @girlonthenet This is how I feel about §8.6.3:

"Secure programming guides from industry recognised sources shall be utilised for each coding language in use and applied to any information system implementation efforts."

Utilised and applied how? And to what extent? With what exceptions?
@BBFC @hasbean @girlonthenet Happy with §8.6.{4,6,7} - but 8.6.8 is fun:

"Age-verification providers shall protect requests, responses and / or transactions that pass over the internet from interception, manipulation, alteration, re-use and unauthorised disclosure."

Disclosure? Like in a public ledger?
@BBFC @hasbean @girlonthenet I am now wondering if those #AgeVerification vendors who are touting a "#Blockchain" as part of their solution, are going to try to have them declared part of a pseudonymisation system to gain protection from reidentification under GDPR; otherwise §8.6.8 seems bad for blockchain.
@BBFC @hasbean @girlonthenet [ I need another break. Actually, no, I need tea. No, wine. Gin. Whisky. But I have to go out later and drive, so I can't drink anything. Damn you all, you have no idea of what you are putting me through. Tea, it must be. Earl Grey. Hot. ]
@BBFC @hasbean @girlonthenet I am popping out for a few minutes, so there will be a pause in service; in the meantime, I wrote an essay in December, explaining how this document _should_ have been built; for someone will surely ask.

@BBFC @hasbean @girlonthenet If you just want the highlight:
@BBFC @hasbean @girlonthenet There's a secret technique which we teach to #infosec neophytes:

- open and read the manual

- find every instance of being told "do not do [x]"

- do [x] and as many variants of [x] as you can possibly think of
@BBFC @hasbean @girlonthenet This is essentially a restatement of another #infosec truism, "blacklists don't work"; any system which says "YOU CAN DO WHATEVER YOU WANT, JUST DON'T DO THIS" is highly likely to be compromised in quite a short time.

There's a lot of it, implicit in this document.
@BBFC @hasbean @girlonthenet "Only the minimum amount of personal data required to verify a user’s age shall be collected" - how much is that?

"A user’s identity shall not be verified as part of the process." - what does "verified" entail, here?
@BBFC @hasbean @girlonthenet "Information about the…website that the user has visited shall not be collected against the user’s activity" - but how will we bill?

"Only industry standard pseudonymisation techniques…shall be implemented" - but will they be an effective choice for the specific deployment?
@BBFC @hasbean @girlonthenet "Age-verification providers shall only share the result of an age-verification check (pass or fail) with the requesting website" - but what else will they share with the requesting website?

This document's approach to data protection is fundamentally flawed.
@BBFC @hasbean @girlonthenet The (considerably) safer approach - one easier to certificate/validate/police - would be to say "everything is forbidden except for <specific operations> upon <specific data> for <specific demonstrable purpose>"; you would then allow vendors to appeal for exceptions under review.
@BBFC @hasbean @girlonthenet It makes a few passes at pretending that this is what it's doing, but with subjective holes (green) that you can drive a truck through:
@BBFC @hasbean @girlonthenet I gotta say, though, that §8.5.12 suggests someone has a clear eye upon the business mentality of some of the key players; this bit is smart, especially given the "we can launch a new cryptocurrency on the back of this!"

Or, at least, it would be smart if it weren't voluntary.

( just in case you haven't worked this out, yet )
@BBFC @hasbean @girlonthenet ONWARD!

§8.7.4 "[AV] providers and third parties who can impact, or who are responsible for maintaining, security and privacy controls shall clearly document each party’s responsibility in implementing and maintaining the relevant controls of this Standard."

And then what?
@BBFC @hasbean @girlonthenet Yet again we run into the whole "this document is architecturally misconceived, voluntary, and essentially toothless"-problem. Why would any company sign up to do this, unless it were for arse-covering as provided by the lowest bidding consultancy?

@BBFC @hasbean @girlonthenet §8.7.6 "Measures shall be put in place to ensure that when a relationship with a third party is ending all access or information provided to provision services is securely destroyed, returned or revoked."

Please define "destroyed"?
@BBFC @hasbean @girlonthenet §8.7.7 "…Information about the original requesting online pornographic service shall never be shared with third parties involved in the processing of verifying a user’s age."

Will (eg:) Mindgeek be a third party unto itself? They own a complete AV-to-Content pipeline…
@BBFC @hasbean @girlonthenet §8.8 - and once again we see the clear contrast between rather strong physical security mandates, versus rather weak/fuzzy digital ones:
@BBFC @hasbean @girlonthenet It's past 9PM and I am still doing this, and oh my god, here's §8.9 - this is THE THING which they proffer as the means to address the yawning gulf between their approach and the likes of PCI.

This is the #PenetrationTesting spec; and…
@BBFC @hasbean @girlonthenet This is how Penetration Testing will happen:

"Penetration testing of [THING] shall be tested by a suitably qualified individual at least annually or after a significant change."

@BBFC @hasbean @girlonthenet If wishes were horses, beggars would ride.
If turnips were watches, I'd wear one by my side.
If "if's" and "and's" were pots and pans,
There'd be no work for tinkers' hands.

If pentest schedules were defences,
we would all be secure. 🤦‍♂️

No GIF on this one.

No graphic.

No link.

This is too terrible; but there's more:
Apparently it's important that things are gotten from "industry recognised sources" - does that mean me?

Also, that "impacts are identified" - and then what?

And "critical" issues have 14 days to fix, but "high" ones have two months. But who says which is which?
Also, it's interesting to note that the "two months" timeframe applies both to "high risks" but also to "non-critical vendor-supplied security patches".

How long are "non-critical risks" given to be fixed, then?
FINALLY §8.10 & §8.11 - Incident Management & Resilience; for the third (?) time we can see that the drafters of this document are far more comfortable with physical, human & operational security, than they are with digital.

This is PRETTY GOOD, there is WHAT and there is WHY:
And that's *it* - what we have here is a rehash of quite a lot of reasonable physical/operational security, business continuity & personnel security management thinking — with "digital" stuff almost entirely punted.

It's better than #PAS1296, but it's still not fit for purpose.
This made me smile - and he's right:

>Roles and responsibilities associated with information security, data protection and operational activities shall be clearly defined and documented by zombies.

>All physical assets shall be documented and maintained in registers with details of the asset, asset owner, asset classification and impact of loss, compromise or unintended disclosure by zombies.
>The organisation’s approach to meet all relevant legal, regulatory and contractual requirements shall be centrally documented and kept up to date by zombies.

This is a good technique for identifying some of the weaknesses.
@threadreaderapp unroll, please. And open a bottle of wine while you're at it?
ps: as suspected, they don't have it covered:
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Alec Muffett
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!