Din Carpați și până-n mare,
Plugul nostru dă strigare:
România, fii deșteaptă,
Nu cădea în cursa lată!

Nici cu ruși, nici cu extreme,
Nici cu falsele dileme.
Ortodoxia-adevărată
E lumină ne-ncetată!

Sincretismul de Valhală?
Nu-i cărare, e doar boală.
Fii român blând și-nțelept,
Să discerni strâmbul de drept.

NATO, Schengen și Uniunea,
Sunt pe bune, nu minciuna!
Să păstrăm ce-i câștigat,
Să schimbăm ce-i de schimbat.

Între frați, fie iubire,
Nu dispreț și despărțire.
Suveranist / mondialist,
Tot român ești: altruist!

Așa-i plugul de povață,
Să ne fie țara-n față,
Demnă, bună și curată,
Să ne fie viața toată.

Ia mai mânați, măi, flăcăi,
Pace-n țară și în văi!

La anul și la mulți ani!

Am compus un plugușor (cu un pic de ajutor*)
*de la chatul gipiti

Let’s say the layout of your project is something like:

And you want to analyze this .NET project with Sonar (SonarQube or SonarCloud). When setting up your CI analysis with the Sonar Scanner for .NET, for example with GitHub Actions, your build.yml would contain the following task for the analysis (I skip code coverage generation in this example):

      - name: Build and analyze
        env:
          GITHUB_TOKEN: \$
          SONAR_TOKEN: \$
        shell: powershell
        run: |
          .\.sonar\scanner\dotnet-sonarscanner begin /k:"<NAME>" /o:"<ORG>" /d:sonar.token="\$" /d:sonar.host.url="https://sonarcloud.io"
          dotnet build .\src\NAME.sln
         .\.sonar\scanner\dotnet-sonarscanner end /d:sonar.token="\$"

This is because you need to run the build (with MSBuild behind the scenes) in order to trigger the Sonar Roslyn analysis for C# or VB .NET. Unfortunately, all your frontend code is in a different folder and, even if it were in the same folder with the solution file NAME.sln, the frontend files would not be referenced (in this example) in any MSBuild project file.

There is a small inexpensive trick to include all the frontend files in the Sonar analysis with the Scanner for .NET. You need to create a dummy CSPROJ file which references all the frontend files. For example, if you create a file src/sonar/frontend.csproj, it should have the following content:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net6.0</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
    <!-- Import all frontend files for the Sonar analysis -->
    <Resource Include="../../frontend/src/**" />
  </ItemGroup>
</Project>

Make sure that you include the newly created frontend.csproj in the NAME.sln MSBuild solution. This trick will tell MSBuild - “Hey, please take these web files as Resources”. The Scanner for .NET includes special target files which, during the dotnet build process, examine the build environment and include all items picked up by MSBuild from ItemGroup. Afterwards, the Scanner for .NET tells SonarCloud / SonarQube later on that those files need to be analyzed (in other words, the scanner “indexes” the files for later analysis during the END step).

If you don’t want to use Resource which may include the file in the project output, you can use None (docs).

However, we are not done. If you run the analysis now, you may see in the logs of the END step entries like the following:

WARNING: File ‘\frontend\src\a\b\file.js' is not located under the base directory '\src' and will not be analyzed.

The good news is that now the Sonar analysis is aware of these files. The bad news is that the Scanner for .NET considers, by default, the base directory of the analysis the directory where the solution file is present. And all indexed files need to be inside the base directory.

To fix this problem, you need to explicitly define the base directory during the BEGIN step, by defining the sonar.projectBaseDir analysis property (for example, to $).

.\.sonar\scanner\dotnet-sonarscanner begin /k:"<NAME>" /o:"<ORG>" /d:sonar.token="\$" /d:sonar.host.url="https://sonarcloud.io" /d:sonar.projectBaseDir="\$"

Bingo. You should see in the logs of the END step something like:

INFO: Sensor JavaScript/TypeScript analysis [javascript] INFO: 1071 source files to be analyzed

At the time of this writing, there is a limitation: the file paths will be a bit ugly in the Sonar UI, because they will be relative to the root folder which contains both the frontend folder with web code and the src folder with .NET code. But hey, you now have them all in one place.

The mind cannot continue in one and the same condition, I mean without receiving addition to or diminution of its good qualities. For to fail to gain new ones, is to lose them, because when the desire of making progress ceases, there the danger of going back is present. (Abbot Theodore in “The Conferences of Desert Fathers” by St. John Cassian)

It’s the end of December, a great time for doing a retrospective of my first year as a public speaker.

I wanted to speak at a conference for a long time. I had already done “Brown Bag Lunch” (BBL) presentations inside Sonar, demystifying technical topics to a mixed technical and non-technical audience (for example, on Object Oriented Thinking). My talks had been appreciated and this feedback encouraged me to think about widening the audience and speaking at a developer conference. Also, I once gave a talk about C# 8 at the local .NET user group in 2019 (recording), so I had the “user group” experience, too.

DotNetDay Switzerland 2022

.NET Day Switzerland was the first time I spoke on a stage. It was awesome and, thank God, I nailed it. In this blog post I will explain how I prepared for it.

Choosing a topic

After I read Alex Bîrsan’s Dependency Confusion: How I Hacked Into Apple, Microsoft, and Dozens of Other Companies article in early 2021, I did a one-week investigation sprint at Sonar to make sure we were safe. Afterwards, around June 2021, I did a small technical presentation to the Languages Team, explaining how the attack works and what were the possible defense mechanisms at that time. Alex, one of our Product Managers, suggested that I do a BBL for the entire company. In the following months I gathered some ideas on how I could present this to a non-technical audience, but did not invest a lot of time in making the presentation.

The opportunity

At the end of March 2022, I found out that the Call for Speakers of .NET Day Switzerland 2022 was still open. Our VP of Products asked me whether the .NET Bubble wants to present something. I asked my team mates, it did not spark a lot of interest, so I wrote down three ideas that came to my mind. One was about “Dependency Confusion” (I already had a sketch for the talk), the second about “Improving the performance for Roslyn analyzers” (we had invested some time in this topic in the previous 18 months for our .NET analyzers) and another one about how “Symbolic Execution” works (a geeky topic, and we had an in-house Control Flow Graph and Symbolic Execution Engine implementation).

Unfortunately, I didn’t have time to prepare the titles and the abstracts, so I sent an email to the organizers for a deadline extension, and Manuel Meyer replied that I could apply until April the 10th.

I applied with the “dependency confusion” and “improving the performance” talks, and the first one got accepted on April the 12th.

Preparing

I knew from my previous BBL experience that preparing a good talk is not easy. And this time it wasn’t a 15 or 20 minutes talk as before, but a 50-minute one.

I didn’t have a lot of time - it was already mid-April and I had to have it ready by the end of August, and I had nothing yet, except two sheets of paper with a sketch. I needed a plan. So I set myself some intermediate checkpoints:

• do a BBL explaining how the attack works to a non-technical audience by the end of May
• prepare the presentation and demo for a technical audience
• present the talk at two user groups before going on the big stage - forcing myself to have an almost-ready version that I could get feedback on from .NET developers who could expose my ignorance on the topic. Initially, I wanted to do one session by the end of June and one in August.

The BBL

I planned the BBL inside the company on the 2nd of June. It was good because I prepared the slides to explain in a visual manner what a package manager does and how the dependency confusion attack works. For this BBL, I created the Mr. Evil Hacker persona to explain the attacks.

I gave the talk from my desk, with almost 200 persons online, some of which gave feedback on the hallways and via Slack, giving kudos for how well I helped non-technical people understand the concepts. Some of my technical colleagues gave kudos for raising awareness. Everyone loved “Mr. Evil Hacker”, they even screenshot me and created a slack :hacker: emoji out of it.

.NET Iasi virtual talk

I wanted to give a virtual talk at the DotNet Iasi meetup, and an in-person one at the Geneva .NET User Group. Unfortunately, the Geneva organisers asked me for the slides before, and I didn’t have them (I was using the meetups to motivate myself to reach intermediate checkpoints).

I got a slot on August the 10th for DotNet Iasi. I had to prepare quite a lot, and it took a couple of weekends to do it: change or improve the existing slides to fit a .NET technical audience, add new slides to explain how to defend against the attack and create demos for the attack, as well for the defense. Moreover, I also added Typosquatting to the presentation (which meant: more demos, more slides).

The talk was fine, although I hadn’t had time to prepare my speech properly. It took a little bit more than one hour - I preferred to have more material that I could remove from for the 50-minute presentation. I didn’t get many questions as I wished at the end. Unfortunately, there was no tricky question and no constructive feedback.

You can watch the recording on youtube - it was an ok talk, but my slides and speech were not polished and in my opinion I did not have a very good energy and vibe throughout the talk. I really needed to change this before going on stage.

Dry-runs in my company

The week before D-Day (the 30th of August 2022), I did three dry runs inside the company - the full show, the “final” slides, the demos, the Evil Hacker change of persona in the middle of the talk. By this time, I improved the presentation, reduced the content and prepared a speech.

The first dry-run was during the .NET Guild Coffee Break (a cross-team meeting for the .NET developers in Sonar), on a Tuesday, hybrid. Most of the feedback I got was related to the content (as expected, because they were the NuGet and MSBuild subject matter experts in the company).

Then on Thursday I did an in-person dry-run with around six people and on Friday I did another one remote-only with four colleagues from various teams. I got plenty of useful feedback on the format of the presentation (slides, speech, story). Not that much on the content itself. And my colleague Andrea pointed me to Patrick Winston’s “How to Speak” MIT lecture, which I watched over the weekend.

The weekend before

The weekend before I initially wanted to chill. However, I went to the local library and I borrowed some books about public speaking. While I was waiting on Saturday evening at a barber’s shop, I was polishing my slides on the phone (greatly simplifying them and making them prettier) according to Prof. Winston’s advice. I considered some hints from the books I skimmed through, although I must admit the “How to Speak” lecture was far superior to what I found at the local library. Even more, the books told me what (not) to eat and drink before the day, and I became stressed by this, too.

On Sunday evening I was still changing the demos a bit. The presentation was due on Tuesday morning.

The D-Day

Initially, I thought I wouldn’t be nervous, why would I? I had previously spoken in front of large audiences at my company. However, I got an upset stomach the day before the talk, probably due to stress. Thank God, the problem of eating got solved - for breakfast, I only ate toast with a little bit of feta cheese, and drank some tea.

In the morning, I joined my colleagues at the Sonar booth (after my talk got accepted, Sonar decided to sponsor the conference). Then I went to the opening key note (a brilliant talk by Mr. Richard Campbell on the History of .NET - very well delivered, I must say). I stayed at the Sonar booth for an hour after, to calm my thoughts and allow my colleagues to go and watch some talks in the first batch. There wasn’t much activity at the booth, so I could calm down.

Fortunately, my talk was scheduled at 10h45, in the second batch, so I did not have to wait a lot. I went there 15 minutes before the talk, as instructed by the organizers. I met the volunteers from the local Swiss .NET community. I plugged in the laptop, verified the contrast of the console and the IDE, changed it from dark to bright at their advice. Attached the microphone, prepared the “Evil Hacker” outfit for later in the talk when I would need it, and I was ready.

I did not have any stage fright. On the contrary, I felt like a fish in the water. My colleague Mary told me there were 50-60 people in the cinema room, less that a normal “Sonar” BBL audience. I had great fun, I did not have any irreparable demo effects, the audience laughed at the “funny” moments. I managed to deliver the talk on time, finishing a couple of minutes earlier.

Furthermore, I got great feedback from people later during the conference. The “Evil Hacker” persona was very well received. And I also got nine pieces of feedback via the feedback form I put on my website. Most of it positive.

Thank God, I accomplished my mission. The session was not recorded, but the slides I used are public on speakerdeck.

There were other cool stuff like the speakers dinner (I got to talk with Richard Campbell for two hours on a variety of topics) and having breakfast at the hotel the second day with renowned speakers. Maybe I’ll write about that at a later date.

VisugXL Belgium 2022

In September I had applied to another .NET community conference (VisugXL) at the end of October, this time in Belgium, and got accepted. I changed the title from “Dependency confusion and its cure. A NuGet story.” to “How to attack a .NET software supply chain”, because one of the feedback I got was that the title was very confusing and mysterious. I also changed the description on Sessionize and included verbatim excerpts from the .NET Day Switzerland feedbacks in the “note to the organizers” section, to “sell” myself.

Before leaving to Belgium I did another dry run - two months had passed since my talk in Zurich, I had to rehearse my talk and the demos. This time, I did it alone, as I was confident on the quality of my presentation. Also, I had modified the slides a little, improving them and adding more content, as this time I had a 60 minutes slot. I removed some slides from the beginning which I considered not so important and I added a “use a lock file” section in the presentation.

Because Sonar paid for the plane and hotel, the organizers gave us a sponsor table at the conference (VisugXL is a small one-day conference, on a tight budget). I went there alone, as a one-man team - I stayed at the booth from morning ‘till I entered the conference room at 15h45. It was a great opportunity to talk with various people, both who knew our products and had various questions or remarks, as well as people who never heard of SonarQube or SonarLint before.

This time I had 26 people in the room, as opposed to the experience in Zurich, here the audience was much more interactive - they were asking questions on the go, which was quite nice. And at the end, we spent roughly 15 minutes discussing various topics. I went over the timebox, but it was the last presentation so that was ok (I planned 50 minutes of presentation and 10 minutes of Q&A, but all in all there were around 20-25 minutes of Q&A instead, hence the spillover). That was a great learning experience, because some of the folks in the room were quite senior and knew many topics better than me! Exposing my own ignorance and learning is one of the reasons started to speak at conferences.

At the end of the day, one of the organizers who watched my talk told me that I could also apply for Techorama. For me, this small interaction was very rewarding.

Geneva .NET User Group

The last session I gave was at my local .NET User Group in Geneva. Like before, I did a dry run before, to make sure the demos still work and that I have a nice flow of ideas. It was on Thursday the 10th of December. Unfortunately, there were only five people in the room, but each of them appreciated the talk, said they learned new things they can apply in their day to day work, and this is a great reward for me as a speaker. The audience was again interactive, asking questions as I was speaking. From some of the interactions I got ideas of hobby projects I could do and I started to think about my next public speaking subjects.

The rejections

This year was my first year as a public speaker. If you aspire to become a speaker at developer conferences, bear in mind that I applied to six conferences in 2022 and only got accepted at two of them. I have a better acceptance ratio at user groups :) (two out of two), so it might be better to start with user groups before applying to developer conferences.

2023

2022 was a great year, I worked a lot for my public speaking debut, I learned a lot from the process, I met a lot of interesting people, I got a plethora of positive feedback and good vibes from the two conferences I participated at.

Last, but not least, one of the .NET Day volunteers told me after my session: “I understood that this was the first time you spoke on a stage. You did very well, you really should continue doing this.”

I don’t plan to stop here, I have some ideas for other talks and I will try to get accepted at bigger developer conferences next year.

However, it will be a lot of work to get there, as I am doing this mostly in my spare time.

Let’s write a target file that opens a browser when being executed.

<?xml version="1.0" encoding="utf-8"?>
<Project>
	<UsingTask
	  TaskName="OpenRemoteImage"
	  TaskFactory="RoslynCodeTaskFactory"
	  AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" >
		<ParameterGroup />
		<Task>
			<Using Namespace="System.Diagnostics"/>
			<Code Type="Fragment" Language="cs">
<![CDATA[
            ProcessStartInfo startInfo = new ProcessStartInfo();
            startInfo.FileName = "https://raw.githubusercontent.com/andreiepure/andreiepure.github.io/master/assets/Evil_Hacker.jpg";
            startInfo.UseShellExecute = true;
            Process process = new Process();
            process.StartInfo = startInfo;
            process.Start();
]]>
			</Code>
		</Task>
	</UsingTask>
	<Target Name="ExecuteArbitraryCode" AfterTargets="CoreBuild">
		<Warning Text="Arbitrary code executed from this task."/>
		<OpenRemoteImage/>
	</Target>
</Project>

This target file:

• defines a Task inside of it (UsingTask) and opens an URL with the default browser. This is a plain C# program, so you can write anything inside (whatever allows the build process to execute).
  • “RoslynCodeTaskFactory” allows creating inline tasks (otherwise, an “AssemblyFile” attribute pointing to the task DLL should be used instead the “TaskFactory attribute)
• defines a target which writes an warning message to the build output and invokes the defined task

Save the above inside a “foo.target” and then execute

dotnet msbuild foo.target

and you will see the warning in the build output an the browser window being opened.

What’s next?

You can insert this malicious target file in a NuGet file and distribute to the entire world. I will write more about that in a future article.

MSBuild is the Microsoft Build Engine. What might be less known is that it offers a scripting language. An MSBuild file is usually a script, orchestrating what happens during the build process.

Concepts

The MSBuild scripting language concepts:

• properties are variables; some are reserved; some are predefined by MSBuild during the build process; others are environment variables; and others are customized in MSBuild projects and props files
• items are inputs in the build system, usually files - these are used to include or exclude files from the build process; each item has some metadata attached to it
• tasks are atomic build operations, like “compile” or “copy file”; there are plenty built-in tasks, and you can define your own by extending Microsoft.Build.Utilities.Task; a task must be present inside a target in order to be executed
• targets are groups of tasks to be executed together; they enable sections of the build process to be called from the command line with the -target: switch
  • targets can have attributes that specify the order of operations (InitialTargets; DependsOnTarget; BeforeTarget) - MSBuild uses this information to build a Direct Acyclic Graph of targets to execute
  • each target runs only once in a single build

Convention

MSBuild offers an XML scripting language. By convention, MSBuild files have a limited set of extensions. However, it is only a convention - any of the below files (or a simple .xml file) can hold the definition of MSBuild properties, tasks and targets. That being said, by convention there are three types of files:

• project files (.csproj, .vbproj, .esproj etc)
• target files (.target)
  • The Microsoft.NET.Sdk target file is referenced in .NET csproj files (<Project Sdk="Microsoft.NET.Sdk">)
  • The Directory.Build.target file is picked up by MSBuild as a customization file in the folder structure of your project
• property files (.props)
  • The Directory.Build.props file can hold build config and is picked up by MSBuild

Tasks are normally kept in libraries (DLLs) which are referenced by other files. MSBuild files can import other MSBuild files. Usually target files reference other target files.

Microsoft offers very good documentation each of these MSBuild concepts.

Hello World script

Create a file, name it “hello.txt” and paste the content below.

<?xml version="1.0" encoding="utf-8"?>
<Project>
	<Target Name="ExecuteArbitraryCode" AfterTargets="CoreBuild">
		<Warning Text="Hello, World!"/>
	</Target>
</Project>

To execute it, run

dotnet msbuild hello.txt --verbosity:quiet

It will output

MSBuild version 17.4.0+18d5aef85 for .NET C:\blog\playground\hello.txt(4,3): warning : Hello, World!

Congratulations! You wrote your first MSBuild script.

As a reminder, these are the easy steps to do in order to secure you NuGet supply chain against typosquatting and dependency confusion supply chain attacks:

1. Use <clear /> to avoid inheriting the system configuration (because of how settings are applied in NuGet). By using <clear />, you ensure the NuGet resolution of your builds are fully deterministic and repeatable.
2. Use Package Source Mapping if you have a hybrid (private and public) configuration, to be protected against dependency confusion attacks. You can use the NuGet.PackageSourceMapper tool to help you generate the configuration for your repository. Alternatively, instead of using multiple package sources, configure only a single package source and control which packages you mirror from the public source in your private source.
3. Use <trusted signers>: see Manage package trust boundaries. You can use trusted signers for both signed packages (when you will provide the certificate hash), and for unsigned packages (by simply providing the name of the account that published the package you trust). This will help defend your project against unwanted typosquatting attacks.
4. Reserve prefixes for both your public and private packages on nuget.org: Package ID prefix reservation. It is important to reserve the prefixes for your private packages so that malicious users won’t publish public packages with those names, to attempt dependency confusion attacks. Reserving prefixes for public packages also reduces the surface attack of typosquatting attacks.

These are my top recommendations. You can find more on Microsoft’s NuGet Security Best Practices.

In addition, to have the overview of all your direct and transitive dependencies and be aware of changes in your dependency graph use a NuGet lock file.

Moreover, a general good practice is to use fixed (pinned) versions for your dependencies, to limit the surface of a dependency confusion attack.

Last but not least, if you sign the packages you publish (both public and private ones), you enable your consumers to use <trusted signers> in the best way possible, by also verifying the signature of the owner (not only the signature of the repository).

Some real life NuGet configurations:

• sonar .NET analyzers (and check also one of the lock files)
• Sonar Scanner for .NET
• NuGetGallery

For more docs from Microsoft and more resources on software supply chain attacks, read the second part of this post.

Last, but not least: we’re hiring at Sonar!

As a reminder, these are the three easy steps to do in order to secure you NuGet supply chain against dependency confusion attacks (links to Microsoft docs):

1. Use Package Source Mapping
2. Use <trusted signers>: Manage package trust boundaries
3. Reserve prefixes for both your public and private packages on nuget.org: Package ID prefix reservation

The source code for my demos is on GitHub, feel free to use it when explaining the problem to your colleagues.

More docs from Microsoft:

• NuGet Best practices for a secure software supply chain
• For Maven, Gradle, NuGet, npm, Pip, Yarn: 3 Ways to Mitigate Risk When Using Private Package Feeds
• MSBuild .props and .targets in a NuGet package
• MSBuild inline tasks

You can read about the NuGet historical design decision of having a non-deterministic package resolution behavior for hybrid configurations (fetching packages from all configured sources in parallel): NuGet/Home#5611.

About substitution attacks - the original article by security researcher Alex Bîrsan from Romania: Dependency Confusion: How I Hacked Into Apple, Microsoft, and Dozens of Other Companies.

About typosquatting:

• Typosquatting programming language package managers (2016) in the NPM, PyPi and rubygems ecosystems
• IconBurst NPM software supply chain attack grabs data from apps and websites (2022) in the NPM ecosystem

About the SolarWinds breach:

• overview, timeline: New Findings From Our Investigation of SUNBURST
• technical explanation of SUNSPOT, the malicious tool that was deployed into the SolarWinds build environment: SUNSPOT: An Implant in the Build Process.
• technical explanation of SUNBURST, the trojan shipped inside Orion: Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor
• SUNBURST Additional Technical Details
• list of victims: The List of Known SolarWinds Breach Victims Grows, as Do Attack Vectors

C. Augusto Proiete demonstrated that NuGet packages can execute arbitrary code in 2019 - i-am-root-nuget-package.

Whether you enjoyed or not my talk, please fill in this Feedback form (Google Form, anonymous).

Last, but not least: we’re hiring at Sonar!

And whatsoever you do, do it heartily, as to the Lord, and not unto men (Colossians 3:23)

I believe that we developers should strive to be replaceable.

What is a “replaceable developer,” in my opinion? One that:

1. puts team cohesion and goals over own goals
2. continuously hands over knowledge to his team (organically)
3. continuously learns from their peers (through code reviews, discussions, pair coding, etc.)
4. helps colleagues grow towards becoming replaceable developers (for example, through feedback and guidance)

Consequently, a “replaceable developer” continuously increases the team’s bus factor, avoiding “knowledge silos.”

And from an individual contributor’s point of view, a replaceable developer:

1. writes clean code
2. ensure his code has high code coverage and high scenario coverage in test automation
3. writes minimal, essential documentation when needed

Points a-c are necessary for any sane developer, for their own sake, not only their team’s.

Thus a replaceable developer brings high value to any team and company. If a “replaceable developer” is sick, takes a sabbatical, or leaves the company, there would be no delivery problem for the team. Consequently, everyone should want and keep “replaceable developers” in their group.

I am aware that agile methodologies are supposed to ensure by design that “nobody on the team is indispensable.” And the desire to be replaceable fits very well within the agile mindset. However, replaceability is more than applying a methodology; it is a working principle.

Becoming a replaceable developer takes time, effort, perseverance, and a healthy work environment. And I believe it is worth it!

Thanks to Liviu, Ghennadi, and Paul for reading drafts of this.

The Privacy Policy

As I like to read the Terms and Conditions and the Privacy Policies before agreeing with them, I spent around 1 hour doing so. And I found some interesting stuff. Note that the following quotes are from the Roborock Privacy Policy which was available inside their Android app on the 27th of December 2020. By the time you read this, things may have changed.

“Your personal information will be retained for as long as necessary to fulfill the purpose for which it was collected, or as required or permitted by applicable laws. […] Roborock will continue to retain any data which will be further processed solely for achieving purposes in the public interest, scientific or historical research purposes, or statistical purposes, even if the further processing of such data has nothing to do with the purpose for which it was collected.”

My problem is that they didn’t mention anonymity here… Basically, they collect data for purpose X and then can use it indefinitely for any purpose, as the categories they mention are vague. Of course, being a Romanian citizen, I am also a European Union citizen and can ask for data deletion, by sending an email to privacy at roborock-eu dot com. Long live the GDPR!

“If you are a European Union user under the GDPR, your personal information will be stored on the server in Germany.” ✌️

Another advantage of the EU.

“Our Privacy Policy does not apply to products or services offered by any third party. […] we strongly recommend that you read the third party’s privacy policy, just as you have taken time to read ours.”

Initially after reading this, I had the impression they were breaching GDPR, because they didn’t mention which 3rd party providers they use. So I sent an email to dpo at roborock dot com and asked them to clarify. They replied within 12 hours, mentioning:

“[…] the third party mentioned in the privacy policy refers to the services provided by other companies that can be used in Roborock app, such as Amazon’s Alexa speakers. Because when you choose the service provided by a third party, you will learn about its data processing through the app, and the data will only be transmitted to the third party after you explicitly agree. Third-party services do not belong to the basic services provided by the app, and the supported services may increase with the upgrade of functions. Therefore, the privacy policy does not disclose the list of all third-party services supported. However, you can learn about the specific situation of the third party through the pop-up prompt in the app before using the related service.”

That’s pretty good customer service. It was a nice surprise.

The Password Policy

After accepting the T&C and Privacy Policy, I had to create an account and choose a password. Here, I had a really bad surprise: they ask for 6-12 chars passwords. Yes. 2020, almost 2021. Maximum 12 characters. The Roborock company ensuring that your password can be cracked without burning too much fuel.

Obviously, I accepted all of this because I want to use my little robot 🤓🤖. But still a bad experience.

The robot experience

As I write this article, we have used the robot twice: first to create a map while vacuuming our home, and the second day just vacuuming. For 34 square metres, it first took 40 minutes (while creating the map) and the second time it took 30 minutes. We can watch the cleaning history in the app, what trajectory the robot took in each session. All in all, it was really easy to setup. The robot is pretty smart, gentle on the furniture when bumping into it and quite organized when moving in the home.

Later update (2021-10-24)

This blog post does not suggest that your privacy is respected by Roborock. I do not know how my data is being used. Also, it is worth pondering whether these gimmicks are truly necessary or not (because Want is the Acid consuming our planet). I haven’t used my Roborock in the past 4 months and I don’t necessarily miss it.