Skip to content
This repository has been archived by the owner on May 16, 2023. It is now read-only.

Worm #160

Closed
decipher2k opened this issue May 27, 2020 · 4 comments
Closed

Worm #160

decipher2k opened this issue May 27, 2020 · 4 comments
Assignees

Comments

@decipher2k
Copy link

If the app will only be usable with bluetooth enabled, then there will be a worm.

@ironjan
Copy link

ironjan commented May 27, 2020

Possible duplicate of #99, #100, and #101, also created by @dennisheine. @SebastianWolf-SAP - may be of interest for you as you were active in the aforementioned issues.

There are many people watching the project (at the moment 257) which receive notifications about new issues and comments. It's safe to assume that most of these people - including me - are neither related to SAP nor Telekom and are actually interested in a productive project. Please take that in mind before creating new issues.

@SebastianWolf-SAP SebastianWolf-SAP self-assigned this May 27, 2020
@SebastianWolf-SAP
Copy link
Member

Thanks for mentioning me, @ironjan Yes, this is indeed a duplicate, not only content-wise but also from a behavioral perspective. We will close this issue accordingly.

@dennisheine You have been warned several times and we did a temporary ban for a few days for violating our code of conduct. As you continue with the same violations after the ban is over, we need to ban you permanently from this project.

Mit freundlichen Grüßen/Best regards,
SW
Corona Warn-App Open Source Team

@sventuerpe
Copy link

@SebastianWolf-SAP

While I appreciate everyone’s – thus far successful – effort to keep discourse civilized around here, I see here also a valid and perhaps not sufficiently answered question:

CWA requires that users enable Bluetooth on their device. Security vulnerabilities in Bluetooth implementations have repeatedly been reported and such reports often conclude recommending that users disable Bluetooth when not using it. What are the implications for CWA and its users?

The actual risk from Bluetooth vulnerabilities for devices and users probably remains low. Widespread Bluetooth attacks have to my knowledge not been observed despite repeated vulnerability reports. Bluetooth is not the most attractive attack surface for mass attacks as access is limited to the physical vicinity of a device, constraining the number of devices an attacker can reach without moving. Even an autonomous attack tool like a worm would spread much slower over Bluetooth than on the Internet.

It seems also unlikely that very may users enable Bluetooth solely for the purposes of contact tracing and exposure notification. In this age of smartphones without a headphone jack and Bluetooth speakers we can assume that a substantial number of smartphone users keeps Bluetooth enabled anyway. Nevertheless, reports of actual Bluetooth attacks in the wild remain scarce, which tells us something about the scenario.

Perhaps @dennisheine’s concerns could be addressed by risk assessment along these lines after acknowledging the adversary model (#123) of a Bluetooth-based attacker.

@corneliusroemer
Copy link
Contributor

Having discovered this issue and the controversy surrounding it, I feel the need to make a few points that may be helpful in future interactions with the community.

I'm surprised that the first time this topic was mentioned (#99) it was closed and locked immediately, the only non-personal reason being that vulnerabilities within Bluetooth implementations are out of scope. As @sventuerpe explained above, this is a valid question that deserved consideration and discussion.

To this extent, I understand that @dennisheine felt the need to reopen the issue - the discussion he rightly considered need to be had was being prevented.

Because this hasn't been discussed, I feel the need to state a few points about the way the author of the issue was subject to code of conduct violation enforcements:

  • The reason he wrote in German may be that he doesn't speak English well. This shouldn't be cause for a warning, it's not a violation of the code of conduct. Recently there have been many bug reports in German, never was violation of the code of conduct brought up as a result.
  • The language used wasn't sober/technical/professional, but shouldn't we have a certain tolerance towards different styles of writing? Again, a stretch to call it a code of conduct violation.
  • Polemical language is not tolerated, that point makes sense
  • His statement "you're forcing users to be hacked by criminals" was misinterpreted. Of course app usage is voluntary, but that doesn't mean that security threats caused by usage of the app should be disregarded. Users are "forced to be hackable" in the sense that if they want to use the app and have a vulnerable phone, they need to enable Bluetooth and thereby become hackable.
    So rather than giving him the benefit of doubt, @dennisheine was warned immediately and not allowed to comment and defend himself.

The next time he raised the issue, this time in English and in a less polemic tone, clearly showing he had learned, he was told "saying sorry and repeating the same statements doesn't make it credible". The maintainers again do not give the benefit of the doubt and ban him - in the eyes of @dennisheine this wasn't really understandable because he presumably didn't see the problem with saying "forced", he understood "forced" presumably in the sense I mentioned above. Of course, he could have voiced his concerns better, but we should have a certain tolerance.

I think for the future it would make sense to have different individuals respond to what is considered a violation of conduct. A ban probably shouldn't be issued without different viewpoints being heard and the discussion being locked immediately. Had another maintainer responded the second time @dennisheine opened the issue in #100, maybe this situation could have been defused. After all, as @sventuerpe shows, the idea raised by him deserved discussion.

I'm not endorsing the tone of @dennisheine's issues - but I think it could have been dealt with better and lessons should be learned.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants