5 ms·

Some details on how this assumption was made would be nice, but I think it's pretty obvious that any developer involved in a project can make a reasonable assum

by hnarn 5y ago

Some details on how this assumption was made would be nice, but I think it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is depending on the technical details on what is required for the bug to happen. For example, if we say for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code, one can make the assumption this use case is very rare without knowing the exact number of users that this applies to, just based on common sense regarding how the application is normally used. edit: The linked github issue says: > The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again.

NullPrefix 5y ago
>for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code This is only rare if you have a small social circle. My circle has multiple first name-collisions of at least 5 participants, but my circle is not very big and the area code is also quite small. Some countries do not use area codes for mobile phone numbers, which are used for Signal, meaning country code is the only area limiting factor.
- desine 5y ago
  >for the sake of argument
  - NullPrefix 5y ago
    Yes. And for the sake of the same argument I made a counter argument, stating that some initially believed to be rare circumstances are actually not that rare.
    - hnarn 5y ago
      "For the sake of argument" does not mean "I invite you to debate this", it means the exact opposite: "let's assume this is correct/we agree/etc. for a while and debate what comes after". So in this case you are doing the exact opposite of what the phrase "for the sake of argument" is requesting. https://idioms.thefreedictionary.com/for+the+sake+of+argument https://idioms.thefreedictionary.com/for+the+sake+of+argumen... > I know you want to go to Stanford, but just for the sake of argument, let's talk about what some of the other schools you got into have to offer. This does not mean "I invite you to make a counter-argument as to why no other schools than Stanford are worth going to".
      - NullPrefix 5y ago
        OKay, M[rs] English-as-a-first-language.
        hnarn 5y ago
        English is my second language.
      - qu4z-2 5y ago
        It sounds to me like NullPrefix accepted the hypothetical bug, for the sake of the argument, and then addressed the rarity assumptions made about that bug. "For the sake of argument" doesn't mean "No debating" it means "Let's assume some thing x is taken as a given and go from there."
        hnarn 5y ago
        The whole point was that "given this assumed rare bug, one can know it's pretty rare". Whether the example is actually rare enough is completely beside the point. If it's not rare enough for you, replace it. The argument comes next: given a rare bug, a developer can make an assumption of how rare it is. Debating the example of rareness is splitting hairs.
    - johnisgood 5y ago
- hutrdvnj 5y ago
  Well he just wanted to make an example. One could also construct an example, where the bug only occurs for people with a rare sequence of unicode symbols (e.g. U+2600 U+2601 U+2602) in their username and have a specific date (e.g. 05.04.1920) as their birthday.
  - NullPrefix 5y ago
    Your argument depends on Signal implementing username support, because we do not support unicode in phone numbers.
    - hutrdvnj 5y ago
      My argument depends on an alternate universe in which signal supports it, everything else being equal, because why not.
      - NullPrefix 5y ago
        Does that alternate universe support phone numbers with unicode characters too?
        ChrisKnott 5y ago
        You are arguing against a hypothetical situation of your opponent's creation. This is like when Ross tried to beat Chandler at Cups
        hutrdvnj 5y ago
        I go to bed now and dream of a universe in which NullPrefix is Ross and continues to argue endlessly.
        deleted 5y ago
        [deleted]
        5y ago
z3t4 5y ago
> The fix itself should make it so that database issues like the one that caused this bug can't happen again. I've said that a few times, and been wrong about it. :D I don't know what they mean by "where a database ID was re-used", but I guess it had to do with caching, and cache invalidation is one of the hardest part in computer programming.
- dane-pgp 5y ago
  > cache invalidation is one of the hardest part in computer programming. Yes, famously it is one of the two hardest parts of computer programming, the other being naming things, and off-by-one errors.
WesolyKubeczek 5y ago
> a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code Sounds like the village a part of my family tree comes from.
varispeed 5y ago
Why would anyone think that re-use of ID was a good idea?
- hnarn 5y ago
  I'm not defending the practice of re-using a database ID, but it's absolutely something that can happen (or change) as an oversight rather than an active choice from the developer.
- doctor_eval 5y ago
  Perhaps that’s why it was a bug?
Griffinsauce 5y ago
> just based on common sense regarding how the application is normally used Just based on assumptions of how the application is used. "falsehoods programmers believe" comes to mind. The uniqueness of names in your example could be false in some (or many? No idea) cultures.
deleted 5y ago
[deleted]
jakequade 5y ago
> it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is ... is it? The fact that a bug exists means there's a logic gap. You can try and patch it with theory, but that's just adding assumption to a scenario created from broken assumptions. Also, the job of telemetry in incident reporting isn't to be vague - its to add precision.
- lmeyerov 5y ago
  There's probably a ratio of bug-report-to-occurrences that they're used to for difference kinds of bugs. Ex: If user-visible security bugs have good report rates, say 100-1000 leaks per 1 report, and 10 reports, then 1K-10K incidents. This is harder in b2b, but in b2c, PM's should have a feel for it..
  - conradev 5y ago
    You’d be surprised how difficult it is to estimate the frequency that someone sees a bug. The only way to have a “feel for it” is to base it on… other data. Say there is a bug that happens in the photo taking flow – you’d need to know how often people take photos in Signal. You’d think you could spitball something for that, but it is actually really hard. But if you log how often photos are taken, then that is a great starting point. But further, lower level logic errors like this, especially ones involving race conditions, are even harder to pin down. That is why on iOS you can log “faults” which are non-fatal but very not-expected events: https://developer.apple.com/documentation/os/logger/3551617-fault https://developer.apple.com/documentation/os/logger/3551617-... They generate reports with stack traces that you can use to a) judge the prevalence of an issue and b) see where it originated

by hnarn 5y ago

NullPrefix 5y ago

>for the sake of argument that a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code This is only rare if you have a small social circle. My circle has multiple first name-collisions of at least 5 participants, but my circle is not very big and the area code is also quite small. Some countries do not use area codes for mobile phone numbers, which are used for Signal, meaning country code is the only area limiting factor.

desine 5y ago
>for the sake of argument
- NullPrefix 5y ago
  Yes. And for the sake of the same argument I made a counter argument, stating that some initially believed to be rare circumstances are actually not that rare.
  - hnarn 5y ago
    "For the sake of argument" does not mean "I invite you to debate this", it means the exact opposite: "let's assume this is correct/we agree/etc. for a while and debate what comes after". So in this case you are doing the exact opposite of what the phrase "for the sake of argument" is requesting. https://idioms.thefreedictionary.com/for+the+sake+of+argument https://idioms.thefreedictionary.com/for+the+sake+of+argumen... > I know you want to go to Stanford, but just for the sake of argument, let's talk about what some of the other schools you got into have to offer. This does not mean "I invite you to make a counter-argument as to why no other schools than Stanford are worth going to".
    - NullPrefix 5y ago
      OKay, M[rs] English-as-a-first-language.
      - hnarn 5y ago
        English is my second language.
    - qu4z-2 5y ago
      It sounds to me like NullPrefix accepted the hypothetical bug, for the sake of the argument, and then addressed the rarity assumptions made about that bug. "For the sake of argument" doesn't mean "No debating" it means "Let's assume some thing x is taken as a given and go from there."
      - hnarn 5y ago
        The whole point was that "given this assumed rare bug, one can know it's pretty rare". Whether the example is actually rare enough is completely beside the point. If it's not rare enough for you, replace it. The argument comes next: given a rare bug, a developer can make an assumption of how rare it is. Debating the example of rareness is splitting hairs.
  - johnisgood 5y ago
hutrdvnj 5y ago
Well he just wanted to make an example. One could also construct an example, where the bug only occurs for people with a rare sequence of unicode symbols (e.g. U+2600 U+2601 U+2602) in their username and have a specific date (e.g. 05.04.1920) as their birthday.
- NullPrefix 5y ago
  Your argument depends on Signal implementing username support, because we do not support unicode in phone numbers.
  - hutrdvnj 5y ago
    My argument depends on an alternate universe in which signal supports it, everything else being equal, because why not.
    - NullPrefix 5y ago
      Does that alternate universe support phone numbers with unicode characters too?
      - ChrisKnott 5y ago
        You are arguing against a hypothetical situation of your opponent's creation. This is like when Ross tried to beat Chandler at Cups
        hutrdvnj 5y ago
        I go to bed now and dream of a universe in which NullPrefix is Ross and continues to argue endlessly.
        deleted 5y ago
        [deleted]
        5y ago

z3t4 5y ago

> The fix itself should make it so that database issues like the one that caused this bug can't happen again. I've said that a few times, and been wrong about it. :D I don't know what they mean by "where a database ID was re-used", but I guess it had to do with caching, and cache invalidation is one of the hardest part in computer programming.

dane-pgp 5y ago
> cache invalidation is one of the hardest part in computer programming. Yes, famously it is one of the two hardest parts of computer programming, the other being naming things, and off-by-one errors.

WesolyKubeczek 5y ago

> a hypothetical bug requires you to have more than ten contacts of the exact same name and these also need to share the same country and area code Sounds like the village a part of my family tree comes from.

varispeed 5y ago

Why would anyone think that re-use of ID was a good idea?

hnarn 5y ago
I'm not defending the practice of re-using a database ID, but it's absolutely something that can happen (or change) as an oversight rather than an active choice from the developer.
doctor_eval 5y ago
Perhaps that’s why it was a bug?

Griffinsauce 5y ago

> just based on common sense regarding how the application is normally used Just based on assumptions of how the application is used. "falsehoods programmers believe" comes to mind. The uniqueness of names in your example could be false in some (or many? No idea) cultures.

deleted 5y ago

[deleted]

jakequade 5y ago

> it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is ... is it? The fact that a bug exists means there's a logic gap. You can try and patch it with theory, but that's just adding assumption to a scenario created from broken assumptions. Also, the job of telemetry in incident reporting isn't to be vague - its to add precision.

lmeyerov 5y ago
There's probably a ratio of bug-report-to-occurrences that they're used to for difference kinds of bugs. Ex: If user-visible security bugs have good report rates, say 100-1000 leaks per 1 report, and 10 reports, then 1K-10K incidents. This is harder in b2b, but in b2c, PM's should have a feel for it..
- conradev 5y ago
  You’d be surprised how difficult it is to estimate the frequency that someone sees a bug. The only way to have a “feel for it” is to base it on… other data. Say there is a bug that happens in the photo taking flow – you’d need to know how often people take photos in Signal. You’d think you could spitball something for that, but it is actually really hard. But if you log how often photos are taken, then that is a great starting point. But further, lower level logic errors like this, especially ones involving race conditions, are even harder to pin down. That is why on iOS you can log “faults” which are non-fatal but very not-expected events: https://developer.apple.com/documentation/os/logger/3551617-fault https://developer.apple.com/documentation/os/logger/3551617-... They generate reports with stack traces that you can use to a) judge the prevalence of an issue and b) see where it originated