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.

1. I can usually pull out my phone faster than taking a card out of my wallet.
2. Phone-based cards typically have significantly higher limits than physical cards. (I can tap hundreds of dollars with my phone, only about $100 on my card.)
3. The phone needs to be unlocked which is safer than the card which just needs to be tapped with no other authentication.
4. One less thing to carry around.

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.

For software to run on a computer it needs to speak the computer’s “language”. This is typically called “machine language” but differs across different hardware. For example most modern Intel and AMD processors speak x86_64. This language has ways to express different operations such as “add these two numbers” or “put this CPU core into a low power mode”. This is the fundamental way that software works, but running in this language.

There are languages that are completely different, such as ARM which is very common on mobile devices and is the language used by Apple’s new M chips. These have basically nothing in common with x86_64.

These languages also evolve over time. For example x86_64 is a significant extension to the older x86 language. For the most part this is fine, it is like the CPU now knows more words, if you use those new words the new CPU will understand them, but older CPUs won’t.

RISC-V is a new machine language. What makes it interesting is that it is a free and open specification. This means that anyone can create a new RISC-V CPU, unlike x86_64 where you need to buy a license from Intel or ARM where you need to buy a license from the ARM corporation. Most people think that this openness has major benefits, for example now anyone can create a new processor which may be better, rather than having innovation being stifled by licensing costs (if you can even get a license) or needing to create their own machine language and require huge amounts of effort to migrate software to it.

Note: It is important not to confuse “machine language” with “programming language”. When people write software they very rarely write code in machine language directly. Usually they use a programming language which is then converted into the machine language of the CPU it will run on.

I thought Apple implemented push notifications? Or did they just say they would? Either way you can file the bug with them I think.

Or wait until they allow you to install a browser that isn’t dragging it’s feet.

I wrote my own. I aimed for a different UX than most services. For my use case I have a few devices that I often share files between. So opening the tool on both devices was a bit annoying. Instead you select the file on the first device and you get a push notification on the other. Then the transfer is done over WebRTC (locally if possible). All communication is done end-to-end encrypted and over your browser’s push service.

Hosted: https://filepush.kevincox.ca/

Source: https://gitlab.com/kevincox/filepush

The problem with Yubikey is that it doesn’t have a good enough management story for broad use. I do use it for a few core sites (like GitHub) but if I lose a key I need to get a replacement and register that replacement with every site I have set up U2F 2FA on. This is ok with a few core accounts but doesn’t scale to the hundreds of sites that I have an account with. I am sure to miss a few and then either I can’t log in with the new key or get completely locked out when I lose that key and get a second replacement.

Yeah, this is important to realize. Most good 2FA implementations offer TOTP which doesn’t need a proprietary app. You can store all of your 2FA secrets in whatever app or password manager you like.

1. Salt doesn’t matter if your password is unique.
2. If they can download data via SQL injection having them log in probably doesn’t matter that much.
3. If they can dump your password/hash they can likely also dump the TOTP secret.
4. A lot of website security expert attention is focused on raising the minimum security level. If you are using randomly generated passwords + auto-fill you are likely above their main target audience.

So yes, it is slightly better, but in practice that difference probably doesn’t matter. If you use U2F then you may have a meaningful security increase but IMHO U2F is not practical to use on every site due to basically being impossible to manage credentials.

So yes, it is better. But for me using random passwords and a password manager it isn’t worth the bother.

It is also worth noting that Firefox Sync is end-to-end encrypted. So the amount of data the server gets is quite minimal. (This is unlike the sync of a lot of other major browsers.) So unless you want to hide your IP and activity times from the host self-hosting isn’t critical.

They’ll brick your device if a part can’t be verified so that isn’t much different they destroying. Maybe they don’t require repair shops to hand over personal info, but they do require device identifiers so I wouldn’t be surprised if that is basically identical.

Is this worse? It sounds pretty similar.

How exactly does Samsung police this? Surely the repair shop could just… not tattle?

Well there is a contract in place and there would be consequences for not upholding the agreement. Sure, they could probably get away with it for quite a while. But it likely isn’t worth the risk, they would rather just out Samsung as being a piece of shit and go on their merry way.

It would be pretty easy to catch this as well. Samsung can just occasionally submit a phone with a known third party part for repair and see if the expected report comes in.