- I have a BSE (Bachelor of Science in Engineering) in Computer Science.
- Incrementing doesn't provide the security requirement here: given knowledge of a current key, it's not possible to compute a past key. With incrementing, it's easy to compute a past key. With hashing, it's not possible to compute a past key.
- I don't see how a single absolute address could be exploitable based on my understanding of the threat model of this library. The library is in charge of erasing the secrets from memory. Once the secrets have been erased from memory, what would an attacker gain from knowing an absolute address?
The only thing that makes sense to me is a scenario with a lot of addresses. E.g. if there's an array of 256 integers, and those integers themselves aren't secret. Then there's a key composed of 32 of those integers, and the code picks which integers to use for the key by using pointers to them. If an attacker is able to know those 32 pointers, then the attacker can easily know what 32 integers the key is made of, and can thus know the key. Since the secret package doesn't erase pointers, it doesn't protect against this attack. The solution is to use 32 array indexes to choose the 32 integers, not 32 pointers to choose the 32 integers. The array indexes will be erased by the secret package.
- > If an offset in an array is itself secret (you have a data array and the secret key always starts at data[100]), don't create a pointer to that location (don't create a pointer p to &data[100]). Otherwise, the garbage collector might store this pointer, since it needs to know about all active pointers to do its job. If someone launches an attack to access the GC's memory, your secret offset could be exposed.
That doesn't make sense to me. How can the "offset in an array itself" be "secret" if it's "always" 100? 100 isn't secret.
- Regarding ads, wouldn't YouTube Premium solve that? Regarding recommendations, YouTube kids allows you to select certain videos, channels, or collections, and only allow your kids to view those that you've selected.
- YouTube Kids has a built-in timer to limit the amount of time kids can watch.
- >All ages benefit from time-limited exposure to social media.
As compared to what? To no exposure? Or to unlimited exposure?
- >“We do limit their time on YouTube and other platforms and other forms of media. On weekdays we tend to be more strict, on weekends we tend to be less so. We’re not perfect by any stretch,”
>He stressed “everything in moderation” is what works best for him and his wife, and that extends to other online services and platforms.
>YouTube’s former CEO Susan Wojcicki, also barred her children from browsing videos on the app, unless they were using YouTube Kids. She also limited the amount of time they spent on the platform.
So they're not completely banning their kids from using YouTube. The current YouTube CEO uses a time limit. The previous YouTube CEO uses a time limit and limits usage to the YouTube Kids app.
Disclosure: I work at Google but not on YouTube.
- 3 problems I can think with my idea are: (1) it makes the tripping less noisy, so it increases the chance someone might ignore or miss the trip. I guess with the right UX that can be mostly sovled. (2) if a bug walks in front of the camera, is that 1 trip or multiple trips? The bug would be visible for multiple frames, so it might do a ton of secret rotations for a single incident, which could present an odd UX to the user. (3) in the original design, there's an asymmetric key that's deleted on trip, which isn't really possible in my design. That means in the original design, if the phone is hacked, that doesn't let the attacker forge security footage, because the phone only has a public key, whereas in my design, if the phone is hacked, that does let the attacker forge security footage, because security is based on a symmetric key/secret. (One thing I don't understand about the original design is why it has both a symmetric key/secret and an asymmetric key. If they're both deleted at the same time, and don't auto-rotate, I don't see what benefit the symmetric key/secret provides.)
One idea to improve the (2) problem is to instead of only rotating the secret on trip, rotate for every frame, regardless of whether a trip is ongoing or not. So if there are 10 photos/sec that would be 10 rotations/sec. And then there can be a boolean in the signed data with each frame (signed e.g. with a MAC using the secret) that indicates whether there's an ongoing trip or not (and also include a timestamp in the signed data). So that means regardless of whether it's tripping, an attacker can never backdate images prior to when the attacker got control of the system.
- Instead of deleting the secret on trip, and requiring a re-arm, it could instead derive a new secret on trip, by e.g. hashing the previous secret. That way you don't have to manually re-arm it, and you get a record of all trips.
Say e.g. a bug walks in front of the camera, tripping it. Then 1 hour a later an evil maid comes in and tampers with the system. In my design, you could look at the photo record, see that the 1st trip was a false alarm, then continue looking at the data, and see that the 2nd trip was something real.
Compared to with the current design, the bug would trip it, then you would get no record of the actual evil maid. You would see the photos of the bug tripping it, and think "oh, it's just a false alarm, I don't need to worry", and trust the computer, even though it's tampered with.
- What do you mean by "exactly the same as your connection setup."? Are you talking about TCP?
This TLS handshake can only happen after the TCP handshake, right? So 1 rtt for TCP, + 1 rtt for TLS. 2 rtt total. (2.5 rtt for the server to start receiving actual data. 3 rtt for the client to receive the actual response.)
- Are you saying there are multiple fonts named "Times New Roman"? I can't seem to find any reference to this online.
- Vibe coded Python can certainly have security holes too.
If you want a language that protects you from the largest amount of problems, how about Rust? Vulnerabilities will still be possible, but at least data races won't be possible.
- underyx was doing the ctrl+f on the original (horses) article, not the negative 2000 lines of code article.
It's a confusing comment. I misinterpreted it myself too originally.
- This is good for Bitcoin.
- >Would you consider a “charity” [...] an org that has killed and maimed tens upon tens of thousands of children to be a good thing or even charity?
I do not consider Planned Parenthood a good thing. However, I will still admit they are technically registered as a charity with the US government.
Friends of the Israel Defense Forces is rated 98% and 4/4 on Charity Navigator.
- >Google’s mission is to organize the world's information and make it universally accessible and useful.
https://www.google.com/intl/en_us/search/howsearchworks/our-...
Disclosure: I work at Google.
- That definitely sounds grotesque to me. Sure not "simply grotesque", but grotesque in a complex way.
- It depends on your definition of "charity". If you're talking about Friends of the Israel Defense Forces, Wikipedia says:
>The organization states that it is the official U.S. charity authorized to collect donations for IDF soldiers.
>Charity evaluators have generally rated the organization favorably.[9]
>The organization is recognized as a tax-exempt 501(c)(3) charity in the United States and has been tax-exempt since July 1983.[2]
https://en.wikipedia.org/wiki/Friends_of_the_Israel_Defense_...
What's the solution though? Stop letting kids play outside? I think the solution should be to reform CPS so it's not so traumatizing, and have more governmental awareness campaigns of the benefits of kids playing outside. I see government billboards all the time about anti-smoking, eating healthy, prediabetes screening. There can similarly be billboards promoting kids playing outside.