4 ms·

Have you any source for that being the reason? https://support.google.com/youtube/thread/114633828/changes-to-unlisted-videos-uploaded-before-2017?hl=en https:/

Have you any source for that being the reason? https://support.google.com/youtube/thread/114633828/changes-to-unlisted-videos-uploaded-before-2017?hl=en https://support.google.com/youtube/thread/114633828/changes-... is all I find, and it says this: > In 2017, we rolled out a security update to the system that generates new Unlisted video links. This update included security enhancements that make the links for your Unlisted videos even harder for someone to discover if you haven’t shared the link with them. That doesn’t imply a leaked key to me (I’d consider that wording dishonest if it actually is describing a leaked key), but rather an increase in the sparsity of the ID space, presuming they were using encrypted sequential IDs.

Dylan16807 4y ago
> Have you any source for that being the reason? Not a particularly good one. > That doesn’t imply a leaked key to me (I’d consider that wording dishonest if it actually is describing a leaked key) I'm not sure exactly what you mean. Even if they did announce a leaked key, I don't think it would go in that paragraph anyway. So that paragraph wouldn't be dishonest no matter what. > but rather an increase in the sparsity of the ID space, presuming they were using encrypted sequential IDs. The reason you do that is because you're worried about key leaks, isn't it? I can't really think of another reason. And then they felt the need to pull the emergency lever and hide all videos on the old system.
- chrismorgan 4y ago
  Do you have any source? Is this something you heard, or an interpretation of your own? (I’m not being hostile, I’d just like to know.) For that matter, have you any definite knowledge that YouTube uses encrypted sequential identifiers for its URLs? Looking from the outside, there’s no visible difference between this approach and something based on randomness, save that something random is likely to be longer because that approach is normally paired with statistical collision avoidance rather than checked collision avoidance. The reason you increase the sparsity of an ID space is because you have discovered a weakness in the generation scheme (which allows faster guessing of valid IDs), faster testing has become possible than you planned for, or occupation has exceeded what you deem to be acceptable probabilities (which could be that occupation has been increasing, or that it was constant but you’ve changed your opinion on acceptable probabilities). If you’re worried about key leaks, merely changing keys gets you only a brief respite for an already-leaked key. In this instance, they gave one month’s notice of a change, and the underlying ID scheme change had clearly occurred about six months earlier. This suggests to me that they did not know of any immediate threat, but were being cautious in just the way they described, for the second or third reason. If they did know of a leaked key, I would expect them to state the consequences more forthrightly in the announcement, and have made the change rather more rapidly than they did.
  - Dylan16807 4y ago
    > Do you have any source? Is this something you heard, or an interpretation of your own? (I’m not being hostile, I’d just like to know.) I don't remember where I first heard it, and I've seen two people who claim to have direct knowledge say so on HN. One specified it was a 3DES key. > For that matter, have you any definite knowledge that YouTube uses encrypted sequential identifiers for its URLs? I mean the whole point is that they don't anymore, but that doesn't change the old video IDs. I have no proof but I'll keep an eye open to see if the supposed key ever becomes more available. > Looking from the outside, there’s no visible difference between this approach and something based on randomness, save that something random is likely to be longer because that approach is normally paired with statistical collision avoidance rather than checked collision avoidance. Youtube can easily afford checked avoidance. They're around a hundred videos a second. And they have good reasons to keep video IDs the same short size. > The reason you increase the sparsity of an ID space is because you have discovered a weakness in the generation scheme (which allows faster guessing of valid IDs), faster testing has become possible than you planned for, or occupation has exceeded what you deem to be acceptable probabilities (which could be that occupation has been increasing, or that it was constant but you’ve changed your opinion on acceptable probabilities). If you’re worried about key leaks, merely changing keys gets you only a brief respite for an already-leaked key. Well yes the claim is they changed the generation because of weakness. And they didn't change keys, they got rid of the key for new videos. > In this instance, they gave one month’s notice of a change, and the underlying ID scheme change had clearly occurred about six months earlier. This suggests to me that they did not know of any immediate threat, but were being cautious in just the way they described, for the second or third reason. > If they did know of a leaked key, I would expect them to state the consequences more forthrightly in the announcement, and have made the change rather more rapidly than they did. They seem to have acted fast enough to avoid any worries, so why act faster? And why directly invite bad press? And if it comes up they could still talk about how unlikely it is to find any specific video, and guessing was always going to be possible, etc.
    - chrismorgan 4y ago
      Thanks for the added detail of 3DES, I’ve found a couple of citations now. https://news.ycombinator.com/item?id=25302558 https://news.ycombinator.com/item?id=25302558 claims direct personal knowledge, and is corroborated by a user zellyn who claims on his own site and elsewhere to have worked at YouTube from 2010–2015. Also https://news.ycombinator.com/item?id=27036740 https://news.ycombinator.com/item?id=27036740 with no bona fides. Very good, it seems they did indeed formerly encrypt 64-bit keys, storing the key in the source code (!!), and now instead generate randomly. It sounds to me like they didn’t have any reason to believe the key was compromised (… though with they key in the repository, it’s trivial for a developer to steal, which is why the approach surprises me so—I’d expect it to be a production environment secret), but decided they didn’t like the risk any more. And apparently it took them until 2016 to actually decide to change their approach, a surprisingly long time given that the key must have been so easily available internally. I expect they checked their logs, because the access patterns of anyone attempting even sneaky (distributed and sparse) traversal would stand out like a sore thumb. I’m putting this information and example in the documentation for my scheme, as food for thought. Thanks!

Dylan16807 4y ago

> Have you any source for that being the reason? Not a particularly good one. > That doesn’t imply a leaked key to me (I’d consider that wording dishonest if it actually is describing a leaked key) I'm not sure exactly what you mean. Even if they did announce a leaked key, I don't think it would go in that paragraph anyway. So that paragraph wouldn't be dishonest no matter what. > but rather an increase in the sparsity of the ID space, presuming they were using encrypted sequential IDs. The reason you do that is because you're worried about key leaks, isn't it? I can't really think of another reason. And then they felt the need to pull the emergency lever and hide all videos on the old system.

chrismorgan 4y ago
Do you have any source? Is this something you heard, or an interpretation of your own? (I’m not being hostile, I’d just like to know.) For that matter, have you any definite knowledge that YouTube uses encrypted sequential identifiers for its URLs? Looking from the outside, there’s no visible difference between this approach and something based on randomness, save that something random is likely to be longer because that approach is normally paired with statistical collision avoidance rather than checked collision avoidance. The reason you increase the sparsity of an ID space is because you have discovered a weakness in the generation scheme (which allows faster guessing of valid IDs), faster testing has become possible than you planned for, or occupation has exceeded what you deem to be acceptable probabilities (which could be that occupation has been increasing, or that it was constant but you’ve changed your opinion on acceptable probabilities). If you’re worried about key leaks, merely changing keys gets you only a brief respite for an already-leaked key. In this instance, they gave one month’s notice of a change, and the underlying ID scheme change had clearly occurred about six months earlier. This suggests to me that they did not know of any immediate threat, but were being cautious in just the way they described, for the second or third reason. If they did know of a leaked key, I would expect them to state the consequences more forthrightly in the announcement, and have made the change rather more rapidly than they did.
- Dylan16807 4y ago
  > Do you have any source? Is this something you heard, or an interpretation of your own? (I’m not being hostile, I’d just like to know.) I don't remember where I first heard it, and I've seen two people who claim to have direct knowledge say so on HN. One specified it was a 3DES key. > For that matter, have you any definite knowledge that YouTube uses encrypted sequential identifiers for its URLs? I mean the whole point is that they don't anymore, but that doesn't change the old video IDs. I have no proof but I'll keep an eye open to see if the supposed key ever becomes more available. > Looking from the outside, there’s no visible difference between this approach and something based on randomness, save that something random is likely to be longer because that approach is normally paired with statistical collision avoidance rather than checked collision avoidance. Youtube can easily afford checked avoidance. They're around a hundred videos a second. And they have good reasons to keep video IDs the same short size. > The reason you increase the sparsity of an ID space is because you have discovered a weakness in the generation scheme (which allows faster guessing of valid IDs), faster testing has become possible than you planned for, or occupation has exceeded what you deem to be acceptable probabilities (which could be that occupation has been increasing, or that it was constant but you’ve changed your opinion on acceptable probabilities). If you’re worried about key leaks, merely changing keys gets you only a brief respite for an already-leaked key. Well yes the claim is they changed the generation because of weakness. And they didn't change keys, they got rid of the key for new videos. > In this instance, they gave one month’s notice of a change, and the underlying ID scheme change had clearly occurred about six months earlier. This suggests to me that they did not know of any immediate threat, but were being cautious in just the way they described, for the second or third reason. > If they did know of a leaked key, I would expect them to state the consequences more forthrightly in the announcement, and have made the change rather more rapidly than they did. They seem to have acted fast enough to avoid any worries, so why act faster? And why directly invite bad press? And if it comes up they could still talk about how unlikely it is to find any specific video, and guessing was always going to be possible, etc.
  - chrismorgan 4y ago
    Thanks for the added detail of 3DES, I’ve found a couple of citations now. https://news.ycombinator.com/item?id=25302558 https://news.ycombinator.com/item?id=25302558 claims direct personal knowledge, and is corroborated by a user zellyn who claims on his own site and elsewhere to have worked at YouTube from 2010–2015. Also https://news.ycombinator.com/item?id=27036740 https://news.ycombinator.com/item?id=27036740 with no bona fides. Very good, it seems they did indeed formerly encrypt 64-bit keys, storing the key in the source code (!!), and now instead generate randomly. It sounds to me like they didn’t have any reason to believe the key was compromised (… though with they key in the repository, it’s trivial for a developer to steal, which is why the approach surprises me so—I’d expect it to be a production environment secret), but decided they didn’t like the risk any more. And apparently it took them until 2016 to actually decide to change their approach, a surprisingly long time given that the key must have been so easily available internally. I expect they checked their logs, because the access patterns of anyone attempting even sneaky (distributed and sparse) traversal would stand out like a sore thumb. I’m putting this information and example in the documentation for my scheme, as food for thought. Thanks!