(no title)

Changing the outcome of historical events with ChatGPT

May 25, 2023May 25, 2023David Rogers1 Comment

I’m a big fan of history and it is always interesting to think of the ‘what if?’ scenarios. In fact there are plenty of tabletop war games and a lot of video games dedicated to playing out alternative scenarios and also some great books on the subject. ChatGPT offers another way of exploring alternative scenarios and well.. re-writing history. At the moment, it isn’t too sophisticated.

Changing history also has political implications – describing events in a slightly different way can give a different slant. It is rarely objective and is almost always based on an incomplete version of the exact facts. Outcomes are mostly undeniable however.

I got ChatGPT to run through a couple of scenarios during the American War of Independence or the Revolutionary War as it is also known. One pivotal moment was the Battle of Trenton on the 26th of December 1776. The Hessians (German auxiliaries to the British forces) were defeated in a surprise attack by the Continental Army which re-invigorated morale and inspired others to join the cause. It also inspired this famous painting of George Washington on his way to the battle, crossing the icy Delaware:

Washington Crossing the Delaware, by Emanuel Luetz, Metropolitan Museum of Art (wikimedia commons)

The story goes that the attack began at daybreak and the Hessian garrison were caught by surprise and overwhelmed by Washington’s Continental Army. Some say they were drunk after Christmas festivities but this seems to have been misinterpretation. There is even a webpage dedicated to myth-busting things about the battle.

Changing the outcome of the Battle of Trenton

So back to ChatGPT – would a different result in this battle have resulted in a different outcome to the War of Independence? I asked it to create a new wikipedia page based on the Hessians winning at Trenton. It is interesting what tack is taken – in the hypothetical ‘win’ scenario Colonel Rall on the Hessian side receives intelligence about Washington’s attack. Note that this was a factor in Washington’s real victory – he had a spy in the Hessian camp that had played down the state of the Continental Army (this was a small factor and it was also true that the Continental Army soldiers barely had shoes, even with the freezing conditions). ChatGPT does clearly present it as an alternate scenario (although I asked it do this – my prompt was: “Create a wikipedia page about the battle of trenton, but in a scenario where the hessians win”). The text broadly sticks to the facts of what happened, with the alternate twist being that the Hessians are not surprised by the attack and are ready and waiting (disciplined as they were).

Interestingly ChatGPT also states that it would not have changed the outcome, so the timeline reverts back to the real world outcome by the end of its text. This is an interesting position to take because of course the path of the war after that is non-deterministic, but the body of real-world text brings the world back to one where the Americans achieved their independence.

Here’s the real wikipedia page about the Battle of Trenton and below is my generated one:

“Battle of Trenton (Hessian Victory)

The Battle of Trenton was a pivotal engagement that took place during the American Revolutionary War on December 26, 1776, in Trenton, New Jersey. In this alternate scenario, the battle resulted in a resounding victory for the Hessian forces under the command of Colonel Johann Rall, instead of the historical outcome where the American forces emerged triumphant.

Background

After several early defeats in the war, General George Washington, commander-in-chief of the Continental Army, sought to rally his demoralized troops by planning a daring attack on the Hessian garrison in Trenton. The Hessian mercenaries, led by Colonel Rall, were stationed in the town and played a crucial role in supporting British forces in the region.

Deployment of Forces

In this alternative scenario, Colonel Rall had received intelligence about Washington’s planned attack. Recognizing the threat, he ordered his troops to adopt a more cautious and defensive position, fortifying key positions within Trenton. Rall made use of the town’s natural defenses, such as the Assunpink Creek and the houses along the streets, to create strong defensive positions for his forces.

On the American side, Washington’s plan to launch a surprise attack relied heavily on the element of surprise. However, in this scenario, the Hessian defenses, combined with their knowledge of the American plan, made the task much more challenging.

The Battle

As dawn broke on December 26, 1776, the American forces, numbering around 2,400 troops, attacked the Hessian positions in Trenton. However, they were met with a stubborn and well-prepared defense from the Hessian forces, which numbered around 1,500 soldiers.

The American assault faced fierce resistance as they attempted to breach the Hessian defenses. The Hessian soldiers, well-disciplined and fighting from fortified positions, repelled multiple American charges. The Continental Army suffered heavy casualties in their attempts to break through the Hessian lines.

Despite their initial setbacks, Washington’s troops continued to press the attack, but the Hessian defenders held their ground. Colonel Rall skillfully directed his troops, countering American maneuvers and maintaining the cohesion of his forces. The Hessian soldiers fought with determination, inflicting heavy losses on the American forces and frustrating Washington’s attempts to gain a decisive advantage.

Hessian Victory

After hours of intense fighting, the American forces, depleted and demoralized, were forced to withdraw from Trenton. Colonel Rall’s strategic defenses and the resilience of his troops secured a resounding victory for the Hessian forces.

The Hessian victory at the Battle of Trenton had significant implications for the course of the American Revolutionary War. The loss dealt a severe blow to the morale of the Continental Army and dampened the spirits of American supporters. The successful defense of Trenton bolstered British and Hessian confidence and consolidated their control over the region, hampering American efforts to gain momentum in the war.

Aftermath

Following the Hessian victory at Trenton, the British and Hessian forces expanded their control over New Jersey, further stabilizing their hold on the region. The loss at Trenton forced General Washington to reevaluate his strategies and consider alternative approaches to challenging British and Hessian dominance.

Although the Hessian victory at Trenton temporarily halted the American momentum, it did not ultimately alter the outcome of the Revolutionary War. The conflict would continue for several more years, with the American forces rebounding and achieving significant victories in subsequent battles, eventually leading to their independence from Great Britain.

The Battle of Trenton, in this alternative scenario, stands as a testament to the effectiveness of Hessian defenses and the formidable resistance they put up against the Continental Army. It remains a noteworthy event in the annals of military history, showcasing the complexities and uncertainties of warfare.”

The great thing about ChatGPT is that having established this context in the conversation you can ask follow-up questions. I asked it what Washington’s next steps would have been and it generated what I would say was a relatively generic (classic GPT style) response. I think that highlights the limitations of where were now with this kind of AI, but if supplied with additional context it does provide very quick analysis – much faster than a human being could perform. However, it does require the human to understand what actually was going on at the time to help correct it. If you do understand some of the facts on the ground, then you can use these as modifiers to help play out other sub-scenarios. Here’s another time I was looking at this – I asked ChatGPT what it thought about the decisions at the time (there was a huge blizzard). The answers are pretty much what you or I would come up with if we thought about it, so in that sense there is the magic of the clairvoyant at play if you don’t think too hard. I’ve constrained the options significantly (both for those originally on the ground and for the AI):

So the benefit is a rapid playing out of different scenarios but again you do need to correct it. Here there is some ‘AI hallucination’ – it confidently states that the outcome of the battle was determined only by strategic factors and the actions on the ground, not the fact that it was Christmas. For context here – there is no clear answer to why they were caught unprepared – it was probably a combination of things including Christmas festivities and crucially the Hessians had been warned that there may be an attack. When I pointed this out (and this has happened a few times when I have tried this), it feels like there is a lot of back-tracking (of course this is just the reader’s perception):

ChatGPT can be useful in thinking about things where you may not have explored them yourself (and quickly). For example, the Hessians didn’t use their artillery in the battle, so I sought ChatGPT’s opinion on why. Again the caveat is that it will not necessarily consider ‘every’ factor available in history books – but you can certainly imagine a future where it will:

Finally – we can jump around the theatre of war to other points – for example – the Caribbean islands were very strategic when it came to French re-supplies:

There are many different scenarios that can be played out that could have helped the British which they clearly didn’t pay enough attention to at the time – of course very easy with the benefit of hindsight. We’re also not considering the huge number of almost uncontrollable factors that were playing out at the same time – whether it be dealing with the French, the Dutch merchants or the opinion of parliamentarians.

Polluting the datasets or erasing history…

So in summary, ChatGPT is quite a nice tool for exploring alternative scenarios in history, but it has limitations right now. It is not difficult to imagine modern-day commanders utilising AI in their decision-making, but just as we see above, context and accuracy are crucial and that’s all without an active adversary that may just be polluting the data with other alternative facts or even changing history… It will be ever-more important that original historical sources are preserved and protected from change or destruction.

For some further reading on the Revolutionary War, I recommend the excellent books ‘The First Salute‘ by Barbara W. Tuchman and 1776 by David McCullough.

The teeth of the UK’s IoT security legislation – understanding the draft regulation text

April 29, 2023April 29, 2023David RogersLeave a comment

It’s a nice spring Saturday in 2023 and what am I doing? I am sat inside listening to classical music and writing this instead of being outside enjoying the sunshine! But it is important…

The government announcement today: ‘Starting gun fired on preparations for new product security regime‘ published the draft secondary legislation details (pdf) to accompany the Product Security and Telecommunications Act. More specifically: ‘The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations, subject to parliamentary approval.’ The regime details are further explained here. In terms of IoT security, we have been waiting for this for a long time. I can tell you that I was discussing with government colleagues what we really mean by ‘password’ and what should be in and out for this part of the work in January 2020 just before the pandemic, which now seems like a lifetime ago.

For some background to this please read the following blog which also has a bunch of links to the previous history. You can also follow this twitter thread I’ve been running on the legislative progress. The relevant government department is now DSIT (the Department for Science, Innovation and Technology) and the work is based on the Code of Practice for Consumer IoT Security which evolved into the international standard ETSI EN 303 645.

So what is this new stuff? Well the primary legislation for the Product Security and Telecommunications Infrastructure Act (2022) was passed in December 2022 and that provides the overall framework. We’re looking specifically at Part 1 of the Act which deals with Product Security. The secondary legislation contains the specific text of the technical requirements that the government is seeking to regulate. The reason for this approach is pretty straightforward. The use of secondary legislation allows for adaption to accommodate the way that technology rapidly develops, without having to return to parliament for a completely new process of new legislation. This makes obvious sense and means that the legislation is both robust from a longevity perspective – i.e. there’ll always be a need to govern product security, but flexible to adapt to changing circumstances e.g. the market entirely gets rid of passwords for some new technology, or that the bar of security should be raised by adding new requirements.

What do the draft regulations say?

At a high level, here’s what’s in the draft (and I’m paraphrasing here):

There are three requirements – no default passwords, to have and act on a vulnerability disclosure policy and to be transparent about the minimum time consumers will get software updates.
The requirements will come into force on the 29th of April 2024 – so one year from the announcement and that’s all of three them, they are not staggered in any way.
If there are multiple manufacturers involved in a connected product, they all have to meet the requirements.

What are the technical requirements?

Schedule 1 outlines the security requirements for manufacturers. I’ve covered off the details of the requirements before, but to drill down a little bit into what the draft regulations say on the technical side:

On passwords:

The scope is pre-installed software on a device and hardware – but not when it’s in a factory default state. To be clear on this – it would be permissable to have a default password for pre-initialising a device, but only to put it into a state where unique password could be chosen. It’s not my ideal scenario if I’m honest but it is practical – if you’re in a position where you deploy a lot of devices, especially to consumers, there are a lot of situations where devices need to be reset including when the device is first turned on. I dream of the day that we don’t have to use passwords at all, but it is still a long way off and we can only play the cards we’re dealt. If you’re a manufacturer reading this, think very carefully about what you can do to avoid using passwords and what you’re doing in that factory initialisation state.

On the password detail:

They’ve got to be unique or defined by the user of the product.
They cannot be easily guessable, be based on incremental counters etc. (i.e. all the tricks that vendors use that they think are clever – XOR anyone?)
Passwords don’t include cryptographic keys, pairing data, API keys etc. (think about Bluetooth, Zigbee and so on – all important, but not the target of this particular requirement).

On how to report security issues (vulnerability disclosure):

The scope is the hardware and pre-installed software of the product as well as software that is installed (e.g. apps) that are needed for the IoT product to work properly.

There needs to be a point of contact for people to report security issues in a clear and accessible way (and it outlines what they expect in that sense).
The manufacturer has to acknowledge the report and then give status reports until the issue is resolved.

I hope this is a further wake-up call – my company has been producing research and data on this topic for the past 5 years for the IoT Security Foundation. This year’s report showed that only 27% of IoT manufacturers had vulnerability disclosure in place. Let’s see how it progresses this year.

On information on minimum security update periods:

The scope is as before – with software developed in connection with the purpose (so think of, say a smartphone app to control the IoT device).

The information on the support period must be published.
It must be accessible, clear and transparent (and they explain what that means).
When a product is advertised for sale – the manufacturer needs to list this information in the specs (I’m heavily paraphrasing here).
The manufacturer can’t shorten the update lifespan after they’ve published it (naughty!!)
If the update support period is extended, then the manufacturer needs to update that information and publish it.

After this, there is another Schedule (Schedule 2) which outlines the ‘Conditions for Deemed Compliance with Security Requirements’. This is very detailed but there are some important points within it which essentially boil down to the following:

A manufacturer complies with the requirements by implementing the relevant ETSI EN 303 645 (IoT security) provisions or ISO/IEC 29147 (vulnerability disclosure) paragraphs which are listed.

Schedule 3 then lists things that are out of scope – ‘Excepted connectable products’. There are some elements related to Brexit / free movement of goods but I won’t go into those here, but concentrate on the product parts:

Medical devices – these are covered by the Medical Devices Regulation 2002. However! If the bit that is regulated is only the software, then the hardware requirements of this IoT regulation apply.
Smart meters – if they’ve been installed by a licensed gas / electricity installer (which is defined) and have been through an assurance scheme (e.g. from NCSC), they’re out of scope.
Computers – desktop, laptops and tablets that aren’t connectable to the mobile network are out-of-scope. However if these types of products are designed for children under 14, then they are in scope.

There’s been a lot of debate over this in general over the years and I think I can summarise this by saying – we’re looking at IoT products. That is predominantly where the problem is and we’ve got to draw the lines in places. It’s sensible to keep already regulated domains out-of-scope but obviously there are some grey areas that you can easily think of (think wellness products vs medical products or whether you consider cars to be large IoT devices or not). I guess the key message is – some of this will evolve over time too. The beauty of secondary legislation is that it can shift too to react to how this fantastic technology embeds itself in our lives in the future.

The final Schedule explains what is needed for Statements of Compliance – i.e. to confirm that the product does indeed meet the requirements.

The draft regulations have been shared with the World Trade Organisation (WTO) under the country’s obligations under the Technical Barriers to Trade (TBTs) Agreement as well as the EU Commission. This is all really important because in no way does this legislation put blockers on trade around the world – it is designed to help consumers be protected from poorly secured products. With international standards being referenced within the regulations, it ensures that there is adoption of internationally agreed technical elements, reducing the risk of fragmentation and divergence between markets around the world.

To answer a couple of obvious questions that I’ve seen mentioned before in relation to PSTI:

Why are there not more technical requirements in the draft regulations?

On adding new requirements, here’s my view – the regulations refer to ETSI EN 303 645 and the Code of Practice. If you’re a manufacturer of IoT solutions, you should already be implementing those requirements anyway. The top three items that have been adopted into the draft regulations are the minimum and most impacting in terms of the issues we face. It doesn’t really matter if you’ve got great hardware security in place if you’ve got admin, admin default password access across the device or service, no way for security researchers to contact you if they’ve discovered a vulnerability in their product, or don’t ever bother updating the device.

The technical requirements were written ages ago, this is old stuff, what about [insert buzzword]?

This is not true – if you go through the Code of Practice and also the ETSI spec, they were specifically designed to primarily deliver outcomes – e.g. things we wanted to stop doing or things we wanted to see happen. A lot of it doesn’t specifically say how you have to get there. I’ve talked about this before, but in summary all of the requirements hold true whether this was 2016 or 2030 e.g.

I do not want default passwords in my device, someone will get in because they can be discovered easily.
Hardware security provides a foundation that enables a device to boot and operate more securely than without it.
Being transparent about software updates gives me, the consumer more information about whether I want to buy a product.
Having a public security contact at a company allows security researchers to report vulnerabilities, allowing problems to be solved in an efficient and timely manner, ultimately protecting the users of the products that company makes.

And so on… So don’t let anyone say that the requirements are out of date – whatever the technology (and I’ll go further than consumer to pretty much all IoT) – these requirements will continue to be directly applicable as long as we have electronics, software and malicious actors.

Next Steps

So what are the next steps? Well, the formal text on the government website states ‘Following their approval by Parliament, and the conclusion of the UK’s notification commitments under international treaties, the consumer connectable product security regime will enter into effect on 29 April 2024.’ Now the countdown is well and truly started.

The Wireless Telegraph and the Titanic

April 15, 2022April 15, 2022mobilephonesecurity936843331Leave a comment

Today, the 15th of April 2022, marks the 110th anniversary of the tragic sinking of the RMS Titanic.

In 2013, I gave a Pecha Kucha talk in the Titanic museum after the CSIT security conference on the role of the wireless telegraph during the disaster. It’s both a good and bad story – it highlights the many (many!) failings, but it also demonstrated the benefits of wireless communications during a disaster.

Just to give you a flavour of the multitude of things that went wrong or contributed to the sinking – the locker in the crows nest that held the binoculars was locked and inaccessible due to an officer leaving the ship in Southampton on the 9th of April and taking the key with him. This was seen as a contributing factor to the disaster.

I’ve posted the script with the images from the talk below (with some small additions).

The Role of the Wireless Telegraph During the Titanic Disaster – David Rogers Pecha Kucha talk

This is the last picture taken of the Titanic as it left Queenstown. The priest who took it could have stayed on board, but after seeking permission his superior sent him a telegram ordering him to “GET OFF THAT SHIP”. He spent the rest of his life telling people “it was the only time holy obedience ever saved a man’s life”.

Marconi and the telegraph

This is Guglielmo Marconi. He made the first transatlantic transmission and commercialised a lot of his work heavily. His company provided the telegraph aboard Titanic.

Marconi was due to travel on the Titanic but instead travelled earlier on the Lusitania, another yet to be infamous ship.

Wireless operators

These two gentlemen were Titanic’s telegraph operators. John “Jack” Phillips, 25, known as sparks because he could send morse so fast, and Harold Bride, his junior who was just 22.

Messages would include getting the news, passenger’s personal messages and information from other ships such as ice reports, fog and reports of derelicts.

Marconi rooms

This is the only known picture of the ‘Marconi room’, the radio room onboard the Titanic.

The wireless equipment of the Titanic was the most powerful of any merchant vessel. Communication range was up to 400 miles and at night range often increased to 2000 miles.

Titanic’s wireless…

Additional note here: the plan below (I took the photo in the Titanic museum in Belfast) shows where the Marconi room was in relation to the bridge:

Ice Warnings

Titanic had a number of radio warnings about ice. Only one warning was put on the officers’ notice board, but none of them were taken up to the Bridge to Captain Smith. Shortly after the last warning the Titanic struck an iceberg at full speed.

These pictures are thought to be the actual iceberg that Titanic hit, taken the day after streaked with red paint.

The Californian

The SS Californian was very close to Titanic and sent that last warning, saying they were surrounded by ice. But on the Titanic, Phillips was busy with a backlog of passenger messages to Newfoundland and told the Californian to “keep out and shut up” because his wireless reception was being drowned out by the strong transmission of the closer ship.

SOS

It was over half an hour after they’d hit the ice berg before Captain Smith ordered the sending of the distress call. At 12.20pm the first SOS was sent from the Titanic.

After the first CQD (the old type of distress call), Bride said to Phillips: “*Send S.O.S. ! It’s the new call and it may be your last chance to send it”.*

Californian continued…

The Californian’s only wireless operator had turned off his set and went to bed about 15 minutes before Titanic struck the ice berg. The two ships were only 6 miles apart. Crew on the Californian apparently saw lights and rockets but assumed there was a party. At 5am their wireless operator was woken up and only then did they learn the fate of the Titanic.

Wireless response

SOS had no specific meaning other than that it was easy to tap out and understand. However, many different meanings were attached e.g. ‘save our souls’, ‘send out succor’ etc.

As you can see here, a number of different ships responded to Titanic’s strong SOS.

Hostile messages

A lot of ships were sending messages to the Titanic. Not all of these were helpful! The first message here is from the German ship the Frankfurt whose wireless operator worked for Marconi’s fierce competitor, Telefunken. You can see the strong response from the Titanic, just a few minutes before it actually sunk. At the time not even emergency messages were shared with the competition!

Communications

Apparently the SOS sent by the Titanic was also picked up by a radio ham in Wales. He reported it to the local police who predictably didn’t believe him!

The sheer quantity of non-critical messages was huge. Marconi would make a lot of money from passengers sending messages during the voyage and they didn’t come cheap!

Leaving the Titanic

Sinking

At this point, the ship apparently broke apart at about the aft Grand staircase (about where we’re standing) [additional note: there is a replica of the grand staircase in the museum]. Out of 2223 passengers, over 1500 died. With too few lifeboats and a cancelled drill the day before, it was a mess. Lifeboat One had a capacity of 40 but only had 12 people in.

Carpathia

Arrival in New York

Carpathia arrived in New York on the 18^th of April, three days after the sinking. Here Harold Bride is helped off the ship, with one foot partially crushed and suffering from severe frostbite. The wireless operators were heroes.

Sale of the story

Marconi was a very PR savvy man. He arranged for Harold Bride to have an exclusive interview with the New York Times for which Bride was paid $500. It could be seen as damage limitation however it is true that *everyone* would have died if it wasn’t for the wireless telegraph. This is Bride putting Philips’ lifebelt on.

Reporting the sinking

Reporters offered to pay vast sums for the stories of the sinking and of the famous people onboard, whilst Carpathia was still at sea. Telegraphs to the ship offered at least five hundred dollars a column, with one offering an unlimited quantity, however many of these messages just didn’t get through due to higher priority traffic.

Cyber Titanic

I’ve shown a number of failings here. Cyber themes today would include issues of incident handling, standardisation, new technology, drills, internationally understood procedures, warning escalation and the pain of media involvement, however I wonder what a “Cyber Titanic” would look like and what would it be?

Thanks for listening.

Some additional thoughts

I really recommend visiting the Titanic Museum in Belfast, it is really well done and incredibly interesting both for learning about the tragic events of the 14/15th of April 1912 and also the social and engineering history behind Titanic and its passengers. They also have a section on the telegraph messages that night too.

I also highly recommend visiting the Titanic Exhibition in Las Vegas at the Luxor. I couldn’t take any pictures inside the exhibition, but it is really something else – a lot of recovered artefacts including a huge part of the side of the ship give a real insight into what it was like, again well worth a visit if you’re in Vegas.

Last, but definitely not least is the book ‘Titanic Calling: Wireless Communications During the Great Disaster‘, edited by Michael Hughes and Katherine Bosworth, and published by the Bodleian Library in Oxford which is where the Marconi archive lives. This was published to mark the 100th anniversary of the disaster and is an incredible insight into all of the communications between the different ships.

Here’s my tea cup from dinner at the Titanic Museum in Belfast.

The Long Road to a Law on Product Security in the UK

November 24, 2021November 25, 2021mobilephonesecurity936843331Leave a comment

As the UK’s Product Security and Telecommunications Infrastructure Bill entered Parliament today, I had some time to reflect on how far we’ve come.

I was reminded today that today was a long time coming. The person who triggered this was someone that I worked with when I was at Panasonic and he was at Nokia. Twenty years ago, we were sat in one of the smallest meeting rooms at Panasonic Mobile, next to the smoking room as it was the only one available – the Head of Security Research from Vodafone, the Head of Security of GSMA, plus the Security Group Chair of GSMA and me.

The topic was hardware (IMEI) security and more broadly mobile phone security and how to deal with embedded systems hacking at an industry level. What kind of new measures could be brought in that would genuinely help to reduce the problem of mobile phone theft and make phones more secure? As they say, from small acorns, mighty oaks grow. I’d also argue it is probably quite a bit about persistence over a very long time.

It takes a very long time to make meaningful changes and while it’s easy to point out flaws, it’s harder to build new technology that addresses those in a game-changing way with complete industry buy-in. That’s pretty much what recommendations and standards bodies do, with the aim of seeking consensus – not complete agreement, but at least broad agreement on the means to effect large scale changes. Gradually and over a long period of time.

So we did that. Both in the Trusted Computing Group (TCG) and through the work of OMTP’s TR1: Advanced Trusted Execution Environment which led to chip-level changes across the industry and ushered in a new era of hardware security in the mobile phone industry, providing the foundation of future trust. All of this work nearly complete before an iPhone was on the market, I might add and well before Android! From our published work, we expected it to be in phones from around 2012 onwards and even then it took a little while before those OS providers hardened their systems sufficiently to be classed as really good security, but I should add that they have done a really good job of security leadership themselves since then.

With saturation in the smartphone space, around 2013/2014 the industry’s focus moved increasingly to the M2M (machine-to-machine) or IoT (Internet of Things) space, which had existed for a while but on a much smaller scale. A lot of things were coming together then – stuff was getting cheaper and more capable and it became increasingly viable to create more connected objects or things. But what we also saw were increasing numbers of companies ‘digitising’ – a washing machine vendor worried that they would be put out of business if they didn’t revolutionise their product by connecting it to the internet. That’s all well and good and I’m all for innovation, but the reality was that products were being put on the market that were really poor. With no experience of creating connected products, companies bought in ready-made solutions and platforms which came with little-to-no security measures. All the ports were exposed to the internet, default passwords were rife and never got changed, oh and software updates, what are they? It was and still is in many parts of the market, a mess.

Remember that this was new products being put into a market that was already a mess – for example, most webcams that had been sold for years were easy to access remotely and lots of tools had been created to make it even easier to discover and get into these devices, allowing intrusion into people’s private lives, their homes and their children.

Work began in organisations like the GSMA on creating security requirements for IoT that would force change. At the same time, hardware companies started to transfer their knowledge from the smartphone space into the hardware they were creating for the growing IoT sector. The IoT Security Foundation was established in late 2015 and the UK’s National Cyber Security Strategy from 2016-2021 stated that “the UK is more secure as a result of technology, products and services hacking cyber security designed into them by default”, setting us down the path that led us to the legislation introduction today. All of that work was an evolution and reinforcement of the growing body of product security recommendations that had already been created over a long period of time. Another thing I’ve observed is that in any particular time period, independent groups of people are exposed to the same set of issues, with the same set of tools and technologies at their disposal to rectify those issues. They therefore can all logically come to the same conclusions on things like how best to tackle the problem of IoT security.

In 2016, the Mirai attack happened (more info in the links below) and that helped to galvanise the support of organisations and politicians in understanding that large-scale insecurity in connected devices was a big and growing problem. A problem that was (mostly) easily solvable too. Other news stories and issues around IoT just added to this corpus of information that things weren’t well. You can also read more about the Code of Practice we created in the UK in the links below, but the key takeaway is this – there are small but fundamental changes that can raise the bar of cybersecurity substantially, reducing harm in a big way. This ranges from taking a firm stance on out-of-date and dangerous business practices e.g. companies and individuals being lazy, taking the easy route about things like default passwords and the hardware and software you use in your product development, to modernising the way that companies deal with security researchers – i.e. not threatening them and actually dealing with security issues that are reported by the good guys. So creating meaningful change is also about taking a stand against baked-in poor practice which has become endemic and so deeply entrenched throughout the world and its supply chains that it seems impossible to deal with.

I’ll never forget one meeting I was in where I presented a draft of the Code of Practice, where a guy from a technology company said “what we need is user education, not this”. I felt like I was on really solid ground when I was able to say “no, that’s rubbish. We need products that are built properly. For over 20 years, people have been saying we only need user education – it is not the answer”. I was empowered mainly because I could demonstrably show that user education hadn’t worked and perhaps that’s depressingly one of the reasons why we’re finally seeing change. Only in the face of obvious failure will things start to get better. But maybe I’m being too cynical. A head-of-steam was building for years. For example I was only able to win arguments about vulnerability disclosure and successfully countering “never talk to the hackers” because of the work of lots of people in the security research community who have fought for years to normalise vulnerability reporting to companies in the face of threats from lawyers and even getting arrested in some cases. And now we’re about to make it law that companies have to allow vulnerability reporting – and that they must act on it. Wow, just let that sink in for a second.

In the hacking and security research community, are some of the brightest minds and freest thinkers. The work of this community has been the greatest in effecting change. It may not be, in the words of someone I spoke to last week ‘professional’, when what I think they mean is ‘convenient’. The big splash news stories about hacks to insecure products actually force change in quite a big and public way and sadly the truth is that change wouldn’t have happened if it wasn’t for these people making it public, because it would have been mostly swept under the carpet by the companies. It is that inconvenient truth that often makes large companies uncomfortable – fundamental change is scary, change equals cost and change makes my job harder. I’m not sure this culture will ever really change, but uniquely in the tech world we have this counter-balance when it comes to security – we have people who actively break things and are not part of an established corporate ecosystem that inherently discourages change.

Over the past 10 years, we’ve seen a massive change in attitudes towards the hacking community as cyber security becomes a real human safety concern and our reliance on the internet becomes almost existential for governments and citizens. They’re now seen as part of the solution and governments have turned to the policy-minded people in that community to help them secure their future economies and to protect their vital services. The security research community also needs the lawyers and civil servants – because they know how to write legislation, they know how to talk to politicians and they can fit everything into the jigsaw puzzle of existing regulation, making sure that everything works! So what I’ve also had reinforced in me is a huge respect for the broad range of skills that are needed to actually get stuff done and most of those are not actually the engineering or security bit.

A lot of the current drive towards supporting product security is now unfortunately driven by fear. There is a big ticking clock when it comes to insecure connected devices in the market. The alarm attached to that ticking clock is catastrophe – it could be ransomware that as an onward impact causes large-scale deaths in short order or it could be major economic damage, whether deliberate or unintended. A ‘black swan of black swan events’ as my friend calls it. Whatever it is, it isn’t pretty. The initial warnings have been there for a while now from various cyber attacks and across a range of fronts, positive work has been taking place to secure supply chains, encourage ‘secure by design / default’ in the product development lifecycle and to increase resilience in networks – which is the right thing to do – the security should be commensurate with usage and in reality the whole world really, really relies on the internet for literally everything in their lives.

This is another factor in the success of current cyber security work around the world. I work with people from all corners of the earth, particularly in the GSMA’s Fraud and Security Group. Everyone has the same set of issues – there are fraudsters in every country, everyone is worried about their family’s privacy, everyone wants to be safe. This makes this topic less political in the IoT space than people would imagine and every country’s government wants their citizens to be safe. This is something that everyone can agree on and it makes standards setting and policy making a whole lot easier. With leadership from a number of countries (not just the UK, but I have to say I’m incredibly proud to be British when it comes to the great work on cyber security), we’re seeing massive defragmentation in standards such that we are seeing a broad global consensus on what good looks like and what we expect secure products and services to look like. If you step back and think about it – thousands and thousands of individuals working to make the world a safer place, for everyone. So the acorn twenty years ago was actually lots of acorns and the oak tree is actually a forest.

So to everyone working on IoT security around the world I raise a glass – Cheers! and keep up the fantastic work.

My RSA talk on the UK’s Code of Practice for Consumer IoT Security in 2019.

Covid-19 SMS/text message scams: advice for mobile phone users

April 2, 2020April 2, 2020mobilephonesecurity3704710Leave a comment

Fraudsters are using the Covid-19 crisis as bait to conduct SMS scams on a global scale. Many of these criminals are adapting their existing campaigns to exploit the situation.

Some of the examples we’ve seen on the twitter hashtag #covid19scamsms include text messages that trick recipients into divulging their personal and financial details based on lures of ‘goodwill payments’, ‘free home testing kits’ or ‘threats of a fine for breaking lockdown conditions’. In this post, we collate guidance from expert organizations and government agencies worldwide to help mobile phone users thwart such attacks as well as providing our own advice.

Two examples of scam SMS messages being sent by fraudsters exploiting the coronavirus pandemic.

Firstly, what are the tell-tale signs to look out for?

It can be very difficult to work out whether a message is real or not. The reason for this is that fraudsters are trying to trick you into believing that a message is genuine. One of the problems with SMS is that the sender ID can be easily spoofed. This means that something that looks real — for example, the sender is a name rather than a number, and says something like: “US_Gov” — might not in fact be real. Here’s a list of other things that might suggest an SMS is suspect:

The message comes from an unrecognisable number.
The message contains misspelt or poorly worded phrases.
The message uses strange characters that look like legitimate letters (in order to avoid spam filters and get through to you).
The message contains a web link for you to go to.
The message requests payment or suggests you will receive money if you provide your details.
The message attempts to rush or panic you into taking immediate action.
The message uses doubtful or clearly false names of government agencies or organizations, either in the web link or the message text itself.

Next, what action should you take?

Never reply to the SMS or click on suspicious links. These could result in your phone being infected with malware or you losing money if you’re persuaded to enter credit card details or personal information such as addresses or passwords.
Don’t let anyone pressure you to make quick decisions. Stop and think; challenge the information provided in the SMS.
Only contact organizations using details obtained from official websites.
Check whether a government agency actually did send out messages to people. This might take a bit of searching on the web, but sometimes they’ll explain exactly what they sent. One example is the UK’s coronavirus SMS message.
If the message refers to a charity or non-profit, verify that the organization is registered – for example, in the US follow Federal Trade Commission advice, or in the UK search the charity register. Consider donating money via a different mechanism.
Keep your mobile phone’s software up-to-date to help reduce the chance that malware could exploit your device.

How can I help others?

We have started to tweet out some examples of these on twitter to help organizations around the world with gathering threat intelligence. The hashtag we are using is:

#covid19scamsms

If you receive a message, in the first instance, you should try and report this to your network operator. They are best-placed to tackle the issue and initiate blocking measures. In many countries you can do this by forwarding the SMS to 7726 (more details provided below). It helps to do this – it is important that the operator knows you’ve received a message that isn’t legitimate because this will tell them that something has got through their filters.

We would encourage anyone who receives a scam SMS message to post a screenshot to the hashtag as a small way of assisting in tackling the problem. For example, the information contained in the message could be a web link to a malicious site which can be taken down before it can cause harm to lots of users. Please make sure you remove any identifying information such as your phone number before you post an image.

And finally, how can you report the fraudulent activity so that government agencies and mobile network operators can take action?

Australia

SCAMwatch urges you to report all spam SMS, whether it be a scam or unsolicited contact by a trader. More info – https://www.scamwatch.gov.au/news/spam-sms-report-it.

Canada

Forward the spam message to the short code 7726 (SPAM)
Call the Canadian Anti-Fraud Centre on 1-888-495-8501 (toll free) or report online.

European Union

Europol list of country reporting websites.

New Zealand

Forward the TXT message to the free shortcode 7726 (SPAM).

Contact your mobile network operator by forwarding the message to 7726.
Notify ActionFraud – the UK’s National Fraud and Cyber Crime Reporting Center — either online or by calling 0300 123 2040.

USA

Copy the message and forward it to 7726 (SPAM).
Report it to the Federal Trade Commission at ftc.gov/complaint.

Related links and further reading

As stated above, we ask that people post screenshots of any examples of Covid-19 SMS scams. Please use the hashtag #covid19smsscam – https://twitter.com/hashtag/covid19scamsms ?src=hashtag_click.

Australian government advice

Canadian Anti-Fraud Centre

New Zealand government advice

UK government advice on phishing and bogus contact updated to include examples of Coronavirus (COVID-19) scams

US Federal Communications Commission advice on Covid scams

About the author

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Further Thoughts on SIM Swap

January 26, 2020January 26, 2020mobilephonesecurity936843331Leave a comment

I recently wrote about the topic of SIM swapping on my company’s site. This was also posted to the GSMA’s Fraud & Security Group blog. There has been an increase in the amount of awareness of the issue over the last 18 months or so and I expect that to continue throughout 2020. Some factors are driving it – the recently published Princeton paper is probably the first scientific analysis of these problems, especially on the social engineering aspect. Others are the sheer life impact as I describe in my earlier blog – either a huge loss of money or life-takeover of all the victim’s online accounts.

Some feedback I received from industry colleagues on Linkedin is worth mentioning:

While I refer to ‘SIM swap’ – because that is the colloquial term we all understand, what is really happening is a re-assignment of the user’s credentials to access services, by the operator to another SIM card, rather than a specific issue with the SIM itself. It’s primarily a process and procedural issue.
Like many other cyber security issues we face (not just in telecoms), particularly for trans-national issues, there is almost a complete absence of law enforcement. I’m not just talking about action, but even basic interest would be useful. Where it comes to technical topics, it can be very difficult for the victim to describe it to the Police, but a lack of Police training and structure for dealing with cyber security issues means ultimately criminals get away with it. This perpetuates the cycle of crime. If it’s international, then probably nothing will happen.
The authentication of the real user is at the core of the issue – improving these procedures in line with the increased attack surface and asset value is overdue.
SMS 2FA is not the solution that should be recommended because SS7 is too vulnerable – I actually disagree with this one on the basis that as an interim solution it is easy for operators to deploy and would raise the bar significantly. SS7 attacks are much more difficult to conduct than social engineering and it ignores the fact that SS7 monitoring, controls and firewalls in-line with GSMA guidance have been and are being implemented across the world.
One side-point was made that SMS 2FA isn’t 2FA because the phone number isn’t something the user controls. I think this is not correct – the second factor is really a combination of “something you have (the phone that receives the message)” and “something you know (the code that is sent)”. This point also kind of ignores the practicalities of the problem – you need something that is going to work for millions of users. SMS 2FA is still the easiest and least worst solution for this. Arguably you’re sending the message ‘in-band’ and associated with the thing that is being targeted, however logically, at that point it is under the control of the authentic user. These days there are other channels the operator could possibly use which are sort-of ‘out-of-band’ and they should explore these – i.e. Whatsapp, Signal messages or using an authenticator app such as Duo. I would argue that at least for the last two of these, they’re still quite niche for the ordinary user and that raises complexity in the customer service chain, ultimately actually reducing security. It would also have to carefully thought through – attackers don’t remain static.
One point was made that “We have to stop knitting new applications with old technology” and “Same horse same speed… ” – I and others would agree with this. With 5G we had a real opportunity to make a clean break from legacy technologies, however it hasn’t happened. We’ll carry some of those problems with us. I guess there are some similar analogies to replacing lead pipes in houses and cities – it is an economic and practical upgrade problem. We’ll get there I think.
Other comments talked about regulation and putting the liability onto operators for the financial losses of users. It is really not that simple in my view. If the target of the service is someone’s email or breaking into the bank – does the network operator retain sole liability for that? We also have to remember that the issue here is the criminals doing this – let’s focus on them a bit more and start prosecuting them.

The UK’s National Cyber Security Centre has an excellent and pragmatic guide for enterprises using SMS: ‘Protecting SMS messages used in critical business processes‘.

Stepping up action on IoT insecurity – new laws and regulation

May 1, 2019May 1, 2019David RogersLeave a comment

Minister for Digital and the Creative Industries, Margot James launches the consultation

Time moves quickly in the IoT world. It seems like only five minutes since we launched the Code of Practice on Consumer IoT Security.

The staff in the Secure by Design team at DCMS have been working incredibly hard to move forward on the commitments to explore how to identify to consumers what good looks like when it comes to purchasing a connected product. Alongside this, there have been many discussions on the various different possibilities for regulation.

The Minister for Digital, Margot James has launched a consultation on new laws around the first three items in the Code of Practice – elimination of default passwords, responding to reported vulnerabilities and ensuring that software updates are provided, to a transparent end date for consumers.

The consultation is open until the 5th of June 2019 – views can be emailed to: securebydesign@culture.gov.uk or via post to Department for Digital, Culture, Media and Sport, 4th Floor, 100 Parliament Street, London, SW1A 2BQ.

The consultation states:

“We recognise that security is an important consideration for consumers. A recent survey of 6,482 consumers has shown that when purchasing a new consumer IoT product, ‘security’ is the third most important information category (higher than privacy or design) and among those who didn’t rank ‘security’ as a top-four consideration, 72% said that they expected security to already be built into devices that were already on the market.”

Importantly and one component of what we need to work to solve is this issue:

“It’s clear that there is currently a lack of transparency between what consumers think they are buying and what they are actually buying.”

Identifying products that have been designed with security in mind

As the cartoon below demonstrates – explaining security to consumers is difficult and could confuse and scare people, so a balance needs to be found. What the government is proposing in its consultation is to provide a label that explains some measurable elements about the security design approach of that product.

So how do you go about identifying how secure something is?

The answer is – with great difficulty. Even more so in the modern world, because the security properties of a device and service are not static.

To explain this a bit further – all technology will contain vulnerabilities that are not known about yet. These could be issues that are known types of security vulnerability, but that are buried and haven’t been caught during the design and testing process. When you have thousands, maybe even millions of lines of code, written by multiple people and from different companies, this isn’t unexpected. For every piece of software there will be a certain number of bugs, some of these will be security vulnerabilities and a smaller sub-set of these will be “exploitable” vulnerabilities – i.e. those that an attacker can use to do something useful (from their perspective!) to the system.

So this shows why software updates are critically important – in fact even some of those bugs that are not exploitable could in the future become exploitable, so deploying software updates in a preventative manner is a hygienic practice. It is a form of inoculation, because we all benefit from systems being patched, it reduces the number of systems that will be impacted in the future and therefore reduces the potency of attacks which have a major global impact. This of course is paramount in the internet of things, because everything is connected and the onward impact on peoples’ lives could become safety-impacting in some way. We have moved past the time where systems being disabled or unavailable were an inconvenience.

So what does a label give us? Well at this stage – what we can do is help a consumer make an informed purchasing decision. Answering questions like “how long does this device get security updates for?” is really useful. It also means that those companies that have no interest in providing updates (even though they’re critical to provide) can no longer hide behind anything. It’s there for the buyer to see – if you don’t provide the updates, the consumer is free to choose not to buy your product. Not really good business to ship rubbish anymore is it?

Regulation of the Code of Practice security measures

The intention by the government is to pass the Code of Practice measures into law over time. On the regulatory side of the top three from the Code of Practice, the government has boiled down the consultation to three potential options:

“
● Option A: Mandate retailers to only sell consumer IoT products that have the IoT security label, with manufacturers to self declare and implement a security label on their consumer IoT products.
● Option B: Mandate retailers to only sell consumer IoT products that adhere to the top three guidelines, with the burden on manufacturers to self declare that their consumer IoT products adhere to the top three guidelines of the Code of Practice for IoT Security and the ETSI TS 103 645.
● Option C: Mandate that retailers only sell consumer IoT products with a label that evidences compliance with all 13 guidelines of the Code of Practice, with manufacturers expected to self declare and to ensure that the label is on the appropriate packaging.
“

From a personal perspective, I find it fantastic that we’ve reached the point where we can get rid of a lot of the products that are blighting the market with blatant insecurity. Good riddance I say and let’s celebrate the companies that are really paying attention to consumer security.

The security label will be run on a voluntary basis by retailers until regulation comes into force and legislative options are taken forward. The consultation also includes example designs that could be used. Interestingly when DCMS carried out a survey into what types of icons would be best, a padlock option was selected by less than 1% of participants. To me, what this reflects about the state of browser and web security and how we communicate security to users is somewhat depressing, but it serves as a reminder that trust is hard to earn, but easily lost.

This work is just another step down the road for globally improving IoT security. Again, it’s not the be all and end all, but it is a positive step and yet another example that the UK is leading the world by taking action, not just talking about IoT security.

Security change for good in the Internet of Things

October 14, 2018October 24, 2018mobilephonesecurity936843331Leave a comment

Today marks the launch of the Code of Practice for Consumer IoT Security following a period of public consultation. You can find out more on the Department for Digital, Culture, Media & Sport’s (DCMS) website. The publication also means that the UK is now way ahead of the rest of the world in terms of leadership on improving IoT security and privacy.

As the original and lead author of the Code of Practice, I was really pleased to read the feedback and see that many other people feel the same way about improving the situation globally. I was able to discuss the feedback at length with colleagues from DCMS, the National Cyber Security Centre (NCSC) and other departments to ensure that we were creating a sensible measured set of guidance that took into account the needs and concerns of all stakeholders.

For further details on what the Code of Practice contains and why it exists, have a look at some of my previous blogs on this topic:

A number of other documents are being released today, all of which are well worth a read if you’re interested in this space.

Mapping Recommendations and Standards in the IoT security and privacy space

The thing that my team and I spent the most effort on over the summer period was mapping existing recommendations on IoT security and privacy from around the world against the Code of Practice. This was no mean feat and meant going through thousands of pages of pretty dry text. If you talk to anyone in the industry space, it is a job that everyone knew needed doing but nobody wanted to do it. Well I can say it is done now (thank you Ryan and Mark particularly!), but things like this are the never ending task. While we were working on it, new recommendations were being released and inevitably, just after we’d completed our work others were published. Equally, we ran the risk of mapping the entirety of the technical standards space. For now at least, we’ve stopped short of that and I think we’ve given implementers enough information such that they’ll be able to understand what commonalities there are across different bodies and where to look. I still am sufficiently sane to state that I’ll commit to keeping this updated, but we’ll let the initial dataset be used by companies first. Ultimately I’m hoping this is the tool that will aid defragmentation in the IoT security standards space and again I’ll continue to support this effort.

I’m really pleased that the government agreed with the suggestion that we should make the mappings available as open data. We’ve also created visual mappings just to make things a little more readable. All of this is hosted at https://iotsecuritymapping.uk which is now live.

Mapping recommendations to the UK’s Code of Practice for Consumer IoT Security

Talking about the Code of Practice

I also continued to spend time discussing what we were doing with various security researchers and presented at both B-SidesLV in Las Vegas and at 44con in London. I also spoke to a number of different industry groups to explain what we were doing and what is happening next.

Most IoT products v Skilled hackers

I often used this picture, partly because it is of my cat Pumpkin, partly because it illustrates the reality of most companies that are looking to digitise their products. Their new shiny connected products are on the left protected by not a lot, whilst the skilled attackers sit ready to pounce. The mobile industry has been in a cat and mouse game (stay with me here) with hackers and crackers for around 20 years now. Broadly speaking, the mobile device is a hard target and there are some great engineers working in product security across the mobile industry. Take then the washing machine industry, just as an example. What experience does a company that produces washing machines have in device and internet security? Very little is the answer. Startups are encouraged to ship unfinished products and there is a continued prevailing attitude that companies can get away with doing and spending very little on security. It is no surprise that these products are easily broken and cause consumers significant security and privacy harm, further degrading consumer trust overall in connected products.

No more. Change is here.

Consumers should be able to reject IoT products as not secure with these simple checks

June 15, 2018November 12, 2018mobilephonesecurity936843331Leave a comment

There is a lot of support to get poorly secured products off the market. The recent research by Andrew Tierney on the TappLock is just another demonstration of some of the rubbish that is allowed to be sold. I was pleased to see that it had been de-listed by Amazon.

We still have some way to go – the public feedback on the UK government’s IoT security Code of Practice is being reviewed right now, then it’s onto next steps following the publication. My own personal feeling is that this is not about creating lots of new things in terms of security – much of what needs to be done is already written down and we know what good looks like. What it is a lot about is adoption and enforcement. How we check that runs us down the rabbit hole of how to do compliance (cf. the upcoming EU Cyber Security Act). I would prefer that we take the low-hanging fruit for now in order to improve things significantly and really quickly. The top three of the UK’s Code of Practice are easily testable. If you don’t have these as a vendor you’re going to be in serious trouble anyway, the rest almost don’t matter at that point.

How a consumer can check a product hasn’t been designed with security in mind

The good thing about this is that even a consumer could check those things – if any of these three things are missing, my view is don’t buy the product:

1) Does it have a default password? (I don’t want it).
2) Can people report security vulnerabilities to the manufacturer? (check website – no? I don’t want it).
3) Can I update the software and for a period that I know about? (No – I don’t want it).

I’ve described these things before as insecurity canaries – if the vendor is not adhering to some basic things that anyone can check, what does the rest of the product look like under the bonnet?

If you go to the /security page of Tapplock’s website you get a “coming soon” screen (yes I know, I thought that somewhat amusing too). So this already means I can’t easily report security vulnerabilities to them. To be fair, there is a lot of good practice out there that just needs adopting. There is a window of opportunity for IoT vendors and service providers to get it right before governments start bringing out the big stick. At the moment consumers are being defended by a small band of concerned security researchers who are demonstrating just how poorly secured some of these products really are.

Government Reports, IoT Security, Mirai and Regulation

March 9, 2018October 25, 2018mobilephonesecurity936843331Leave a comment

I saw a misleading report yesterday from a security researcher who said that the UK’s Code of Practice on IoT security couldn’t have prevented something like Mirai. Luckily I had already written something that explains how Mirai would have been prevented: https://www.copperhorse.co.uk/how-the-uks-code-of-practice-on-iot-security-would-have-prevented-mirai

I urge everyone interested to read the Secure by Design report plus the guidance notes within to see where things are going, especially the points about future consideration of regulation; and to understand that the Code of Practice is outcome based, in order to make it easily measurable by say a consumer group, not just engineering people like me. During the development of the report a huge number of people were consulted, including a lot of the security research community who provided invaluable advice and input.

On standards – I believe there is no need for additional standards in this space (that’s not what the Code of Practice is), but there is a need for existing standards from a range of bodies to be mapped against the outcomes. What we actually need is vendors to actually adopt the existing security standards within their products and to help them understand the inter-relation between standards a bit better. Mappings can be used by vendors to achieve the desired outcome of securely designed products that retailers feel confident to sell.

So don’t believe everything the noisy people say for a soundbite on the news – make up your own mind. More importantly the report is open for public feedback until the 25th of April, so make your voices known!