If the day comes when it's impossible to watch Youtube without ads I'll have to leave, despite how important youtube is for me currently. I just can't watch ads. It's impossible. I don't watch a single TV channel with ads, it's too painful.
So, advertisement-supported "moving pictures" (or sound, for that matter - I never listen to radio channels serving ads either) is out of the question, with no exceptions for me personally.
I'm well aware that I'm an outlier here which is why I stated "in my mind". Not sure why you feel the need to write "HN bubble strikes again" except for a lack of reading comprehension or an attempt at trolling.
I also assumed that by saying "in my mind" you mean "in my opinion". English is not my first lamguare, but I think this is a reasonable reading?
If you wanted to say "youtube is not important enough for me" then your post reads weird - what is youtube going to get away with? Losing you personally? I think they'll get over it.
Yup. Only way we can possibly win is by writing computing freedom into actual law. Make it literally illegal for them to use cryptography to violate our freedoms. Service providers should be required by law to interoperate with our computers, no matter what software we choose to run. If we reverse engineer their little apps and make free software versions, they should have to suck it up. We used to be able to buy whatever phone, modem or router we wanted and hook it up to the network with no issues. Software should work the same way.
I'm thinking about a corollary to Net Neutrality (which is allegedly coming back thanks to the new Biden-appointed FCC commissioner) which states that public web sites need to be accessible by the public. I've ranted about this a few times on HN. This isn't about working around bugs and quirks in umpteen different versions of umpteen different browsers, but making sure we don't start actively coding hard stops again: "Your browser is too old" messages, endless Captchas, purposely giving one browser a clearly worse or even unusable experience. Incompetence would be embarrassing but not illegal. Whenever I find the time, I really want to send the FCC a registered mail packet with my proposal and lots of examples of why this is already necessary.
And yes, the web sites will need to suck it up. You can't choose your visitors...which may occassionally be a bot or screen scraper.
Who? The people paying thousands of dollars for locked down mac devices they never modify, the ones giving all their data to social network and clicking on ads or the ones sending money to the NPC streamers to watch them licking an imaginary icecream?
Yeah, and looney toons are bullying apologists, pokemon is child endangerment and animal cruelty, batman beats people instead of creating a better world with his money...
15 years ago I worked with a guy on NGO projets in Africa.
The projects were either prototypes, concepts, in testing, or small scales. Plus he was honestly the type of manager that was better at talking than doing so I wouldn't say he was much involved in them apart from claiming he was doing good.
Well, it worked because he was in the top 100 people of Time magazine the year after for "saving millions of children".
It's pretty interesting to me to see these patterns of who gets credit and who doesn't. My ex-wife got off of active duty and joined the national guard to go to college nearly 20 years ago before she got back in as an officer through ROTC. While she was in the guard, she deployed with a civil affairs unit to Djibouti, which we have always maintained a permanent presence in to secure shipping lanes for oil. She was their supply sergeant and she identified a problem with the local water supply and got them all the equipment they needed to fix it, and in the process probably legitimately saved at least thousands of lives. She got a bronze star for it, but certainly no magazines will ever have heard of her.
It's even more interesting that she got branch-detailed to the field artillery when she got back in, and I'm pretty sure she became the first female to ever command a combat unit in the Army when she filled in as XO of a forward line battery and they lost their permanent commander. But you'll never see her in a history book or read about her on Wikipedia because it was still illegal at the time for women to serve in combat units at all, and officially she was on the books as part of the brigade headquarters company, only filling in because they were severely understaffed.
I try to keep her in mind when I feel like I'm being slighted at work and not getting sufficient recognition for accomplishments as I earn a salary triple what she gets as a Lieutenant Colonel now.
Every now and again, I think I'm in danger of becoming too cynical. It seems that I still have some way to go before my naïvety is properly calibrated to the real world.
Will get more and more difficult. This morning Youtube kicked me out because I was using adblock origin. And update fixed it, but if they start putting DRM...
TBH, Metaverse still hasn't taken off yet. But Blockchain already has quite a place in cryptocurrency. Actual, useful applications... like buying drugs on the dark web.
Reading their docs: No real benefits, just misconceptions.
1. Collision resistance / "weak" PRGNs used to generate UUIDv4. Firstly, these are properties of the implementation, not the spec. Secondly, the source for calling the browser `Crypto.getRandomValues()` insecure is an issue that has been fixed back in 2016. I would not trust the developers of this implementation to do a better job than current browsers.
2. "Not URL or name friendly": Fair, but not very strong argument.
3. "Horizontally scalable" and "offline-capable": No argument given for why UUIDv4 does not meet these requirements, apart from point 1 above.
4. "Too fast": No argument given for why having a slower algorithm to generate random ids is more secure. Both UUIDv4 and Cuid2 use a similar number of random bits (122-124). When using a secure PRNG, both are equally difficult to guess, the SHA3 hashing doesn't add anything. You don't have to try and guess the "input" of the Cuid2 - you can just try to guess the "output" and skip the SHA3 hashing. It would be impossible to actually guess a generated ID, but UUIDv4 is just as impossible. Also no argument given for why UUIDv7 is fine but UUIDv4 is not.
I've used UUIDv4 for genering unique IDs for over 10 years now. I have run into collisions, when I hand-rolled my own implementation for J2ME with major bugs many years ago - ended up with around 20 bits of entropy instead of 122. That's not a reason to not use UUIDv4, just a reason to not implement it yourself unless you really know what you're doing.
I once had UUID collisions in Linux Boot IDs when we started developing our own embedded systems at my company.
Found them because systemd-journald isn't very happy when Boot IDs repeat and (apparently, then) stops showing earlier boots once it hits a repeating boot ID. And I wanted to see an earlier boot. Then I started logging the Boot ID in a textfile myself and it took less than 10 reboots to have duplicate Boot IDs.
Long story short, some weeks earlier, I "optimized" the Kernel config for that system and some config flags that didn't sound like something I'd need. As it turns out, an ARCH_ZYNQ target apparently also needs ARCH_VEXPRESS set. Otherwise it works absolutely fine, but with a broken RNG that you will notice weeks later.
That was a valuable "don't take down a fence until you know the reason why it was put up" lesson. Don't unset kernel config flags until you know why they are set.
Aside from breaking RNGs, I've never experienced any UUID collisions either.
"A couple of years ago we decided to standardize the use of sequential integer IDs as primary keys, due to the significant performance issues of non-time-ordered UUIDs."
From the article. I'd like a lot more exposition on that, since it goes against some of what used to motivate UUID use in the first place. Sequential ordering across distributed nodes isn't a fun thing to do, and even if you navigate the coding, the network agreement makes it really slow.
Do they mean "sequential enough" but some locality of the node that generated it? And I guess that prng can sometimes have some performance bottlenecks, but compared to doing locks on a single incremented integer?
Yeah, I don't really get this, lots of usual "better" "faster" etc without actual numbers to back it up or detailed algorithmic discussions.
As you basically said, wake me up if it's good enough to get into the standard vetted libraries of UUID generation.
No argument given for why having a slower algorithm to generate random ids is more secure.
If the algorithm is too fast it means you can detect when some other part of the system is having a significant impact on how the key is returned. Eg checking a database to see if a user exists and returning their key versus getting null back and generating a new key. That difference can be used to determine if a user exists. You want your key gen process to be slow enough that it's a significant part of the process, which makes timing attacks hard.
This doesn’t make sense.
If you’re going to generate a new key if the user doesn’t exist then you’re creating a new user anyway, so there’s no hidden information.
Unless you mean that the system should return a bogus id instead of a status 40X when the user doesn’t exist, which makes even less sense.
ID generation should usually only happen when creating new assets, so it should be as fast as possible.
Some of the arguments mentioned are explained elsewhere in the README, others are assumed.
One argument standing out for me is the lack of collision-resistance for UUIDv4 which is surprising for me and I didn't spot any sources for that argument.
Another argument is the entropy source where they go about that Math.random is not reliable as a single entropy source but glimpsing at the source code, they sprinkle the CUID with Math.random data.
I am no expert in ID security, so I am not qualified to speak about the validity of their arguments, only that there's insufficient information to validate without prior knowledge about the problem domain.
The chat, admin and moderation features in discord have huge value and are costly to build. The anti-bot protection and built in permission system especially.
They focus their resource on their product, while exposing it to mostly geek.
I would have never though it would be a good idea, but it proved to be a good choice.
Google home page, the most visited site in the world, had an ad spot for chrome inviting you to install it. Not the search result page, no. The home page, the empty white one with only one field.
This spot has never been available for any non google product, BTW.
I predict youtube will escalate this way:
- Pump up aggressive anti ad block measures.
- It will fail, so they will enforce DRM so that they have control.
- It will not be enough, so they will ask to only serve DRM to "trusted browsers".
- And it will not suffice, so the trusted browser will have to run on a trusted OS checked by hardware.
That will work since almost nobody will take the risk to jailbreak their expensive device.
And we will all have lost.