I don’t think that is true. Not much at Google really bought into the UUID hype. At least not for internal interfaces. But really there is no difference between a UUID v4 and a large random number. UUID just specifies a standard formatting.
I don’t think that is true. Not much at Google really bought into the UUID hype. At least not for internal interfaces. But really there is no difference between a UUID v4 and a large random number. UUID just specifies a standard formatting.
It is true, don’t do it.
Even at huge companies like Google, lots of stuff was keyed on your email address. This was a huge problem so Google employees were not allowed to change their email for the longest time. Eventually they opened it up by request but they made it very clear that you would run into problems. So many systems and services would break. Over time I think most external services are pretty robust now, but lots of internal systems still use emails (or the username part of it) and have issues.
IIUC Google accounts now use a random number as the key. But there are still places where the email is in use, slowly being fixed at massive cost.
It depends a lot on the hash functions. Lots of hashes are believed to be difficult to parallelize on GPUs and memory hard hash functions have different scaling properties. But even then you need to assume that an adversary has lots of computing power and a decent amount of time. These can all be estimated then you give yourself a wide margin.
Yeah, but my point is that I use my master password enough that random characters are still memorable while being faster to type. For me personally there isn’t really a use case where the easier memorability is worth the extra characters to type. But of course everyone is different, so it is good that this system is laid out for them with a great guide.
Yeah, that is what I meant by “strength of the hash”. Probably should have been more clear. Basically the amount of resources it takes to calculate the hash will have to be spent by the attacker for each guess they make. So if it takes 1s and 100MiB of RAM to decrypt your disk it will take the attacker roughly 1s and 100MiB of RAM for each guess. (Of course CPUs will get faster and RAM will get cheaper, but you can make conservative estimates for how long you need your password to be secure.)
It is a good technique to be sure, but I haven’t found it useful in my everyday life. In practice 99% of my passwords are stored in my password manager. I only remember like 3 passwords myself. For those I want them to be easy to type as I do it semi-regularly (whenever I turn on my computer or phone, my phone sometimes re-verifies, …). These may be slightly easier to remember but end up being much longer. I find that I don’t have issues remembering the 3 passwords that I actually regularly type.
In fact I recently switched my computer passwords to be all lowercase, just to make it easier to type. I’ve offset this reduced entropy by making them longer (basically shift+key is similar entropy to key+key and easier to type, especially on phones or on-screen keyboards).
The recommended 6 words produces incredibly strong passwords. The equivalent with all lowercase would be 16.5 characters. Personally I went for 14 characters and in my threat model that is very very secure. But this will also depend on your attack model. If it is a disk encryption password or other case where you expect that the attacker can get the hash then it will depend on the strength of the hash and possible attacker’s computing power. If it is protected by a HSM that you trust you can get away with short PINs because they have strict rate limits. Any decent online service should also have login rate limits reducing required entropy (unless the leak the hash without resetting passwords, then see the above point where the attacker gets the hash). All of my memorized passwords fall into the category of needing very strong security but I still found that remembering a random character password that only only took about a week when entering it once a day.
Technically yes. But the method is by far strong enough that this isn’t an issue. This is sort of always the issue with calculating entropy. We say that password
has less entropy than Ni'[
. But that is baking in assumptions about the search space. If password
is a randomly generated string of lower, upper, numbers and symbols it is just as secure as the latter. (808 ≈ 1015 candidates) but if password was generated as just lowercase characters it is far less secure (268 ≈ 1011 candidates) but if it was a random dictionary word it is not very secure at all (≈ 105 candidates) and if it was chosen as one of the most popular passwords it is even less secure. How can one password have different entropy?
The answer is basically it matters how the attacker searches. But in practice the attacker will search the more likely smaller sets first, then expand to the larger. So the added time to search the smaller sets is effectively negligible.
What may be more useful is the “worst case” entropy. Basically the attacker knows exactly what set you picked. For the password
case that is 1 because I just picked the most common password. For the rolling method described above it is 65^6 ≈ 1023 because even if they know the word list they don’t know the rolls. You may be able to go slightly higher by building your own word list, but the gains will probably be fairly small and you would likely get far more value just by rolling one more word on the existing list than spending the time to generate your own.
select a set of words from the list
I would be very careful doing this. It is very easy to introduce significant bias. Humans are terrible at picking random numbers.
If you can’t find dice I would recommend:
Most credit card issuers don’t issue credit cards to random apps by solo developers.
I don’t know about YouTube but the chunks are often a fixed length. For example 1 or 2 seconds. So as long as the ad itself is an even number of seconds (which YouTube can require, or just pad the add to the nearest second) so there is no concrete difference between the 1s “content” chunks vs the 1s “ad” chunks.
If you are trying to predict the ad chunks you are probably better off doing things like detecting sudden loudness changes, different colour tones or similar. But this will always be imperfect as these could just be scene changes that happened to be chunk aligned in the content.
I would pay a lot of money to see Nintendo’s conniption over having to allow home brew and non-approved software on their game consoles. I would love to release emulators for older Nintendo consoles for the Switch so that they don’t get to keep charging people again to play old games on newer consoles.
Because to implement this you need to negotiate with individual credit card issuers. Basically how this works is that your phone is being issued a virtual card with the keys locked inside the phone’s HSM. Then it can be used to make NFC payments just like any physical card. So you need 1. contracts with many card providers, 2. card issuance processes with these providers 3. huge amounts of compliance bureaucracy. At the end of the day it isn’t really worth it unless you are a huge company and expect to have tons of users or see it as an essential feature of your phone OS.
Exactly this. It isn’t even really “stitching” as YouTube videos are served as a series of short chunks anyways. So you simply tell the player that there are a few extra chunks which happen to be ads. There is no video processing required it is basically free to do it this way on the sever side.
So don’t watch it? I would rather the platform all all legal content then trying to be the morality police.
I would also prefer to use third party recommendation engines (like people posting on Lemmy) then one run by any particular platform.
We don’t need a new platform. We need 20 new platforms, and authors can post on whichever ones are best for them. Have real competition and real incentive to be better.
I feel the same way. Or felt. It is a wonderful platform that will let anyone upload and share videos at absolutely no cost. Video hosting isn’t as expensive as we are often lead to believe, but it isn’t cheap. Especially if you want to provide a great experience like different resolutions and qualities.
I used to subscribe to YouTube Premium and was quite happy about it. However they slowly made the platform worse and worse. At some point it hurt to give them money, even if the subscription was “worth it”. I just didn’t like giving money to people destroying a great platform.
Luckily YouTube still supports RSS. This means that I can easily mix in other video platforms with no bother. I now subscribe to Nebula and have 35 subscriptions there. I also have a handful of PeerTube, video podcasts and other self-hosted creators. It isn’t the “majority” of my subscriptions (Apparently I have ~200 YouTube channels that I subscribe to, but a huge number of them are dead, second channels or incredibly infrequent.) but it doesn’t matter. All of my subscriptions come to the same “inbox” and it doesn’t really matter what platform they are on.
It’s not “inherently insecure” at least not to that degree. (Once could argue that lack of E2EE is insecure.) If you stand up an unrelated instance you shouldn’t be able to access private messages that don’t relate to an account on your instance. So only bugs in your instance, or your conversation partner’s instance, will be able to leak those messages.
Because proprietary JS is non-free software and they are against running non-free software.
FTFY