mrb

Sorry you went through that! It must be frustrating.

As an ex-Google ISE, part of my work was to review security vulnerability reports to us. If this report came on my lap I would definitely have flagged this as a severe security issue. Just a DoS yes, but a severe DoS. I did tier two engineering reviews though. From the website's timeline it seems like a tier one triager dismissed it. And I would see this happen occasionally: tier one triagers either dismissing things that shouldn't, or the reverse, flagging things that don't deserve it. My personal opinion is that the quality of Google's work has declined somewhat in the last decade. Disappointing...

Florida statute 836.10 puts the bar at the "sending, posting, or transmission of, a [...] record, in any manner in which it may be viewed by another person"

I think the defendant could successfully defend themselves by claiming they did not know (or intend!) the message could be viewed by another person, as they were plainly using it as a private diary.

What the water figures show is that water usage is not the problem of these data centers. It's a drop in the bucket, literally. Yet another way to see it is that given the average weather in Lincoln, NE (29 inches of rain annually) it rains 480 million gallons annually on the 600 acres campus that Google's data center is located on. So it would be possible to collect only 3% of this rainwater, and it would be enough to cover all their water needs. Water, at the local scale of this campus or city, is an infinitely renewable resource.

Other issues than water are far worse, like pollution associated with the manufacturing and running of all the data center gear. Water is not the issue.

Yes. As another comparison point, 13 million gallons per year amounts to 24 gallons per minute which is about 5 (five) bathtub faucets running 24/7/365.

The water bill alone would be only $100k/yr assuming average US domestic rate of $8 per 1000 gallons.

"You didn't care to have any inkling of memory of the vesting schedule in 1996, or just to double check and "wrap up" the financial details of that agreement after the work was done?"

Give the guy a break. It was a check of 700 bucks for exercising shares in a small (at the time) company that was not even public. Most people would probably not notice the error in the 1 year vs 4 year exercise schedule. Especially because 4 years is the standard, so that seems rather normal to agree to that even though it was an error and differing from the original offer.

As usual, the key to explain the discrepancy between LG's claims and the paper 2024 is in the wording. Read carefully: LG claims it "does not collect screenshots, screen recordings, video recordings, voice recordings, or other audio recordings from the TV.". IOW they are making the technical distinction between "fingerprinting" and "screenshots or recordings".

And specifically, they are not confirming or denying that video fingerprinting are done.

What I think is likely is, as the paper states, that they fingerprint both audio and video. Upload both to their servers. But they end up using only the audio fingerprint for ACR. In this situation, neither LG's statement, nor the paper's statement, nor the GamerNexus folks's claims are incompatible with each other.

It even makes sense from a technical standpoint: it is far easier to uniquely identify content by audio than by video, as a fingerprint of a few milliseconds of audio is pretty darn ideal, compared to fingerprinting even a single video frame which has hundreds of ways it could be compressed depending on codecs, bitrate, resolution, etc.

We all understand your point: you believe the feature is unnecessary in the first place, without any understanding of my particular situation why I actually need it.

Regardless, this is irrelevant to the point of this entire thread, which is that it's possible to design a device, as I did, that is vastly simpler than commercial doorbells allowing user-customizable chimes.

You still fail my challenge: design a wireless doorbell that has a user-configurable chime (eg. MP3 file provided by user), in a way that uses less software or less hardware than mine. You couldn't.

Then I want you to justify why commercial products offering this feature have 10-100 times more code or 10 times more complex hardware just to do what my doorbell does :-)

You completely missed the part that the chime needs to be user-configurable, ie. play a custom MP3 file.

You don't provide that.

"The sound is not customizable"

This is EXACTLY the problem! Try finding one that I can customize with my own chime and you will only find expensive, unreliable, over engineered stuff.

It would be over engineered if one could design a system providing similar functionality using less hardware and less software.

I challenge you to design a wireless doorbell that has a user-configurable chime, in a way that uses less software or less hardware than mine. You couldn't.

In fact, if you did market research like me you would find that 99% of similar products have vastly more complex hardware or software or services being them. They break when there is no Internet. Some work without Internet but don't work when the local Wi-Fi is non functional. They don't immediately get back online after a power outage. They need regular software updates during which the chime can't play. These are over engineered things. Not my product, because mine has none of this complexity or faults.

That is exactly over engineered crap I want to avoid. I don't want my doorbell to depend on networking or a full blown Linux stack.

The requirements are not over engineered. They are what they are. Wireless and configurable chime. They are fixed parameters.

But my implementation of these requirements is absolutely not over engineered. I argue it is the simplest and most reliable it could be done.