PayPal

I've used PayPal for years - it provides a payment platform which means I don't have to share my bank or card details with every organisation. It has - until recently - been good at maintaining an appropriate level of security on the account, and allows use of my preferred 2FA authentication apps.

However recently I've noticed a privacy-hostile attitude which is driving me away from the platform altogether.

One of the key benefits PayPal has created in recent years was linking to bank accounts directly, rather than using cards. This meant that when cards were replaced I would no longer need to update PayPal. If your PayPal account is compromised the attacker would be able to access your verified payment methods and make a load of purchases. If you noticed the hack you might cancel the cards - or cancel the direct debit on the bank account for PayPal.

Card issuers usually apply stronger anti-fraud than direct debit agreements, so it would be easier to make fraudulent payments through PayPal linked to bank accounts - which is why 2FA is really necessary.

If you notice issues, you could get in touch with PayPal and ask them to suspend the account until the issue can be verified.

So far so good.

However as I discovered towards the end of summer this year, and whilst overseas in the US recently, PayPal have become hostile to the kinds of privacy tools I use ... such as the VPN. If I tried to access my account whilst using a VPN that could be identified by PayPal, they would instantly lock my account.

I have MFA set up, and a verification phone number. That means that once I've entered the correct username and password the platform asks for a six digit number generated by an authentication app on one of my devices. That number sequence is unique to that device and cannot be moved to another device. The key (six digit number) is rotated every 30 seconds.

Occasionally I've seen them send me an OTP (one-time password) via SMS too, I would assume they do this both periodically to ensure the method continues to work, and if a string of transactions are unusual - but not totally suspect. However if someone has stolen your phone and unlocked it - don't use patterns, fingerprints or facepalm ID - they'll have access to your MFA key apps and SMS.

This is a standard approach - if you don't use one of these apps I'd recommend FreeOTP, which implements open standards and is open source (published by Red Hat).

I generally use a good level opsec across a number of different topics, and this is largely to remove my traffic data e.g. web and DNS, from access by companies monetising or filtering / traffic-shaping that data. A lot of the security work I do means that I want to reduce the information surface area as much as possible to prevent counter-investigation or intrusion.

When this PayPal account lockout happened the first time I phoned them and went through the security checks to get my account unlocked. Non-SMS MFA was part of that process which I was glad to see. Whilst the call handler was waiting for responses from the security team I asked why the account had been locked to start with.

I was told that the authentication platform had probably detected VPN use and assumed illicit access was being attempted. Although I pointed out that MFA was enabled and that an attacker would have to compromise four distributed devices to get to the information needed, the answer was that "...VPNs are an indicator of dangerous activity.". I've never heard anything so ridiculous.

Some months later I tried to login to PayPal to use a local food ordering service in the US, and again the account was initially blocked. Using a VoiP number for the UK I again spoke to PayPal and this time asked if my account could be marked to allow non-standard access, seeing that MFA was enabled. The call handler claimed that they couldn't do that, and that unless I accessed the website from my own country this would always happen.

Turns out the Android app does something similar and is thus effectively useless. Google also drives a lot of it's app infrastructure to get their permissions and access via Google Play Services, which means many apps no longer need to ask for specific permissions. I'm not 100% clear on whether that means that an app can access Body Sensors on-device via the Play Services service without explicit permission or not.

I've noticed that when using a safe DNS provider (either our own corporate network which strips malvertising or a public anti-ad DoH DNS provider), a number of apps fail authentication with errors. On initial inspection this appears to be because the tracking tools used are embedded in the authentication mechanism, and therefore disabled at a network level. PayPal appeared to have done this for a while as have TSB. Not sure tracking app usage during login is a good idea, especially if the tracking platform is somehow compromised. Tracking is not authentication or authorisation.

None of the security reasons given by PayPal for these approaches seemed to hold any water - why discriminate against VPN or Tor users? PayPal has historically been hack and breach free, it's still possible to get caught by phishing attacks. I don't open any emails alleging to be from PayPal (even payment receipts) as I would normally check the app on a regular basis.

Some configurations and bug bounties paid do make you wonder though.

To solve the problem at the time, I simply used a VPN through an existing tunnel to remote back to the UK and log in to PayPal. Although this time it was to cancel recurring payments and try and remove payment methods.

Despite removing all recurring payments associated with them, I was not allowed to remove any of the payment methods I'd asked to remove. I'll speak to the bank and cancel the direct debits instead - the first stage of replacing PayPal with something more privacy-friendly.

Maybe I'll go back to the protections of credit cards for online transactions, despite having to be concerned that organisations are not fully PCI-DSS compliant (or get hacked themselves).

DVLA Statistics - And How to Save £146m over ten years

Information is Free

Since becoming entangled with the DVLA, I'd raised a couple of Freedom of Information requests (FOIRs) and a subject access request (SAR). By law an authority is allowed 20 working days to respond to a FOIR, and can choose to either respond in full; respond in part (perhaps noting another authority which may hold the relevant information); or refuse to respond to the FOIR entirely.

In this last case authorities often hide behind the section 12 requirements, which detail the process to follow where the request exceeds the time or cost limits prescribed for different types of authority. I noted in my previous DVLA post in which instrument of law those limits are defined.

DVLA are set the ceiling of 4.5 man days or £600 - whichever is higher.

The scene is now set for each of the two FOIRs I raised.

FOIR #1 - Budget Information Relating to Physical Post

This should have been a fairly simple call to the DVLA accounts department, in order to get some basic information. I would have been fine with the more detailed item breakdowns being refused or declined, as long as the base figures were provided.

I asked the DVLA for figures relating to both the previous and current fiscal years:
- the DVLA budget for that year
- the amount spent printing documents to send to registered keepers e.g. fines, new V5Cs, reminders etc
- the amount spent on postage / delivery for these items

I expected the fiscal years for n-1 and n-2, rather than current (n) and n-1, as in-flight accounting is unlikely to be available. In the FOIR I was more specific as I thought it would help DVLA scope the request better, and leave less room for clarifications back to me. How wrong I was.

Initially the request was rejected under section 12 as being too onerous, until I pointed out that when working on programme budgets at most of my clients, I could get most of these numbers over the phone whilst I wait. I also pointed out that they'd already responded to my other request with the actual number of documents sent to drivers, which must have involved a similar amount of work (see the FOIR #2 section below).

I requested an internal review and DVLA responded with some of the information I'd asked for.

So the total spend on:

• all stationary was £1.1m in 2017-18 & £1.2m in 2018-19
• all postage was £25.9m in 2017-18 & £26.2m in 2018-2019
• all printing was £14.4m in 2017-18 & £14.2m in 2018-2019

The total expenditure across these items was effectively £41.4m and £41.6m in 2017 and 2018 effectively. Yet they still essentially refused to supply their overall budget for those years. As I couldn't find a reference to this figure anywhere else on gov.uk I was reliant on this single public sector organisation for those numbers.

I then asked them to reconsider their position but expect them to walk away from this request. Their initial response was later than the FOIA allows, and their responses were evasive at best.

You can see the live FOIR here for reference.

FOIR #2 - Document Production and Delivery Statistics

This one went a little better and information was slightly more forthcoming. But it was still a struggle to get basic information from them.

I asked the DVLA to provide statistics / their records for the following:
- The number of physical documents sent to registered keepers
- The number of those documents sent via some form of recorded delivery
- The number of known tracked items that have a "missing", "undelivered" or similar category applied after they have left DVLA

Despite the specificity of the request, three weeks later the DVLA asked me to clarify what documents I was referring to. I clarified regardless and the final (late) response to the FOIR was received almost a month later.

It turns out that the DVLA sent 99,461,763 documents from Jan 2018 to 25th October 2019. Based on 662 days in that period and assuming the report was generated on the same day as the DVLA response letter; the average number of documents sent per day is 150244(.355).

That's a lot of documents. Only about 32k of those in that 622 day period were sent via some sort of recorded delivery, and the DVLA does not track how many of those tracked items were returned or otherwise undelivered. The DVLA did not disclose how much they spent on tracked / recorded delivery, so this is an assumed and unknown uplift on the cost-per-document-sent.

Now if we combine the responses of FOIR #1 and FOIR #2 we can say (quickly excusing my shoddy maths) that:

1. In 2018-2019 DVLA spend £41,629,644 on document production (excluding 3rd party costs such as GSP)
2. In 2018-2019 we can infer that in 365 days - and using the docs / day from earlier in this FOIR - the DVLA sent 54839189(.57) docs in this year
3. Therefore the cost-per-item to the DVLA in 2018-2019 is £0.79
4. This does not include the DVLA operating expenditure on the processes surrounding this document e.g. hiring staff to manage the processes, interact with the processes and operate processes where necessary, recorded delivery costs, heating, lighting, utilities and other standard OpEx items. The actual cost is probably between £1 and £2 (if the DVLA are operating efficiently).

In the same request I asked the DVLA to explain the QA processes which govern how they ensure the mail service providers (MSP) - UK Mail and Royal Mail - certify that they've collected all the documents produced.

The response on this front have been unclear at best and plain evasive elsewhere. I part of their more recent response the DVLA state:

"Data is input into the DVLA’s systems in accordance with specific parameters,
depending on the type of transaction. This includes a quality assurance check, which allows for work to be appropriately batched ready to send out."

That's a very broad description without any specifics, that doesn't really tell us anything at all. What parameters? What QA check is actually performed? They also stated in the same response:

"When a document is printed, it is then tracked electronically through the mailing system. This supports integrity checks until the document is enveloped and transferred to the Quality Assurance (QA) section. Some items of mail may then require reprinting.

The DVLA then hands over the items for despatch to the respective Mail Service
Provider and is reconciled against control document"

This is more related to the question, and sounds like a proper answer on the face of it. However the portions of sentences I've highlighted should draw attention to the subtle evasion here.

So a document is tracked (per-item?) through the mailing system, so that the QA section can verify it in its envelope. Are they checking every single of the one hundred million items the claim to have sent since Jan 2018?

Finally the point about the "control document" is very vague - is this the DVLA's control document, and one which the MSPs do not interact with? In order words how are the DVLA verifying each letter is accepted by the MSP, instead of just picking up a box or pallet of mail which hopefully includes all the items DVLA has "tracked" to that point?

In fact if we reference a FOIR from 2009, we can see the DVLA admit that the MSP do not verify each item in the batch. I've asked DVLA to clarify a point relating to this as the answer seems a bit more thought out than the one a decade ago. I suspect they have no way of verifying that the MSP is collecting all the items they've printed (so can't entirely blame the postie for lost mail).

You can see the live FOIR here for reference.

Next Steps

Even if my earlier assumptions for calculation were correct (which I know they aren't), the minimum being spent per item is 79p. It's far cheaper for the DVLA to send a prospective fine, on the chase they can intimidate someone into paying than it is to actually review the case properly. It's a cash generation game.

I've largely exhausted options with FOIR as DVLA are likely to essentially ignore further clarifications on the request. Together with their breach of the Data Protection Act (DPA) I'll be putting together a formal document for breaches of FOIA to the regulator, ICO. This complaint will hopefully ensure the DVLA directly answers any outstanding questions.

A grey area has formed between the FOIA and the DPA where automated decision making affecting a living person is at the forefront. GDPR Article 22 deals with ADM - more specifically ensuring that adequate protections are put in place. These protections are aimed at ensuring that an individual suffers no undue harm. In fact Article 22 Section 3 states: "...safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision."

It appears the DVLA has breached this if ADM was at the core of the decision to fine and prosecute me originally. We cannot say that the DVLA has delivered on this requirement by virtue of pressing for prosecution in a case which it later manually determines not to have merit. This is not covered by the FOIA and must be considered by ICO.

In parallel to that I'll be raising complaints with DVLA directly, as was the suggestion of the DVLA prosecutor in the case I won. This complain will focus on recovering damages and distress.

IR35

I can't resist a poke.... the IR35 changes in 2018 will have killed off any IT projects at DVLA reliant on a contingent workforce of consultants. Those same consultants would have been able to build DVLA a digital presence which would remove the need for documents across a conservative estimate of 50% of use cases. A web-based dashboard with services to encapsulate authentication, authorisation and enable notifications to DVLA such as SORN. More and more people have access to the internet via smart-phones, less and less have no access at all - there are still post offices for the rest of the forms.

Eventually other businesses would want to integrate with DVLA data sources, as insurers already do via MID. The motorists data is already held by DVLA in order to support the production of drivers licenses, and therefore the authentication model should focus on driver-based logins. Data security will be key here considering the kinds of information involved. Ideally using MFA such as smartphone authenticator apps should provide a welcome layer of security, and open-source libraries are available to achieve this. The data layer is the most complete layer as it stands today.

Fines, penalties and reminders could all be dealt with in the first instance via the dashboard, with email notifications send to drivers when new 'documents' are sent to them by DVLA. Delivering these digital journeys will need the most engineering & testing effort. The DVLA claims its processes are largely automated so the integration architectures will need to be carefully designed - and probably brought up-to-standard. The DVLA already accepts payments for car tax online if you have a V5C or V11, so existing authentication and payment API's will need to be re-used and expanded upon.

A project of one feature team working on a digital dashboard, authentication model and microservices based on COTS would cost up to £750k for six months. That's a large feature team costing btw, probably one which would operationally be split into two agile teams sharing architect, BA & programme manager. Each team would have it's own scrum master, engineering and QA peeps. Software and licensing for SaaS, for example might stray into the £1m purchase, and £500k annual licence at worst for this kind of thing.

So making some wild assumptions and adding bloat as it's public sector, I did the following in LibreOffice Calc.

Large assumptions ahoy

I made the following assumptions for this:

- I don't know what architecture would be deployed that is compatible with Gov.uk strategy, so upped the IaaS costings for services, services and networks to 75k / year. This increased cost assumes redundancy and performance needed to support the traffic from potentially 90% of motorists in the UK

- I assume the Gov.uk is continuing with vendor-locked arrangements with Oracle, and Oracle are strong-arming Gov.uk as they are with anyone else. Ideally I'd focus on an open-source approach with something like RHEL, Apache, ELK and PostgreSQL, but I don't know how the x-charging works so assumed a DVLA-owned license cost of half a million per annum; plus new costs of authentication and integration of existing Gov.uk payment gateways

- Purchase of cloud and dedicated tin combinations, plus new infrastructure or services hosted for DVLA (assumed re-use from other Gov.uk departments such as MCOL or local government)

- A feature team costing based working over a two-and-a-half year delivery period; including 2 year build and test continual drops, with six months post-live warranty
- These are finger-in-air-estimates for design & development knowing nothing about what really goes on behind the scenes at DVLA

Any of the programme managers I've worked with at my past clients would've fallen off their chairs at those numbers and assumptions, but that's because they work in pragmatic, efficient and competent environments in the private sector.

So based against only a 50% reduction in printed documents - on the assumption that proportion of people register for paperless DVLA services - the DVLA expenditure on disclosed production would be £20,814,822 (ignoring increases with inflationary-associated costs). That's the cost of documents that no longer need to be printed and can be provided direct-to-drive with assured delivery. How many problems does that solve? :)

So the DVLA would save around £20m per annum OpEx, and expend £11m CapEx on rolling out the digital presence? Ok so those savings wouldn't be fully available until year 4. Over the ten year projection that's £145,703,754 cost savings on direct document production alone, versus a £7m run cost estimate over the same period. Still £137m can pay for a lot of tour buses for Boris Johnson.

How to achieve this? Get HMRC on a leash so they no longer exceed their authority under the law and stimulate what's left of the British economy by encouraging the vibrant, consultative small business.

Or keep flushing money down the drain and drive the skilled consultancy workforce out of the UK. You choose.