This seems like a legitimate concern. I didn't see any indication that the snowcone presented a code that would be verified through the aws opshub application, or a similar operation. Is this happening behind the scenes, maybe in the manifest file you upload?
If this was swapped in shipping it could potentially just work as expected while exfiltrating data whenever it could connect to the internet, potentially through builtin lte, etc.
> we will allow the
SSO IDP (Identity Provider) to sign a binding of a Zoom public key to an SSO identity,
and to plumb this identity through to the UI.
> Second, we allow users to track contacts’ keys across meetings.
This way, the UI can surface warnings if a user joins a meeting with a new public key.
> we will implement a mechanism that forces Zoom servers (and SSO
providers) to sign and immutably store any keys that Zoom claims belong to a specific
user, forcing Zoom to provide a consistent reply to all clients about these claims. Each
client will periodically audit the keys that are being advertised for their own account and
surface new additions to the user.
> In Phase IV, we look to the future where Bob should sign new devices
with existing devices, use an SSO IDP to reinforce device additions, or delegate to his local
IT manager.
All of this of course relies on a zoom client actually doing everything described in the whitepaper, but it certainly looks like a good faith effort to implement real, functional e2ee
Not sure if this is possible with the current WebRTC api, but if you could expose the dtls public keys for the current and remote sessions somewhere, that would help to reduce the risk of MITM attacks. Users would at least have the option of manually verifying keys through another channel.
edit: it looks like you can find info in the RTCSessionDescription.sdp property. The remoteDescription and localDescription should each have key fingerprints in lines with "a=fingerprint:..."
If the benchmark is bound by the database speed, wouldn't the expected result be that all implementations returned roughly the same number of requests per second?
Having worked briefly at a major appliance company, I can say that refrigerator design is not simple. Refrigerators aren't made to just cool things down, the entire interior is expected to stay at a uniform temperature. As a result, many refrigerators have more heating elements than ovens. There's a ton of testing that needs to happen to determine hot spots, cold spot, poorly insulated areas, etc. and that's just for the cooling. Also the current refrigerant used in refrigerators (driven by regulation) is very close to propane, it has an explosion risk, so that mandates tons of specific testing. The real issue is that the release cycles of appliances are so much shorter than the expected life cycles. There are life tests for appliances, but they have to be accelerated massively, so it's not a great representation of the lifetime use of the appliances. All of that to say the data collected by an internet connected appliance is of huge value to the manufacturer. They can get data from the appliance for it's entire life, usage and performance of specific components, etc. Manufacturers are going to find as many cheap ways as possible to tempt consumers to connecting their products to the internet so they can get that data back. It's unlikely the trend is going to slow down.
I'm not an expert in the field of refrigeration so I'm speculating a bit, but I believe the won't work because the cause of inconsistency of temperature is that the insulation isn't as effective at every part of the cabinet (probably due to shape, what components are packed around the cabinet, etc.) so moving air over those areas would cause heat to enter the cabinet faster, requiring more cooling power. That might be effective, but I think the approach that's taken is more efficient, and that's what refrigerators are all about (They move like 2-3x more heat energy out of the cabinet that is put into the compressor, fans, etc.). The less movement of the air inside the more effective the insulation will be.
It's also worth noting that just insulating better isn't really an option (without developing better insulation) because refrigerators need to have as large as possible interior volume compared to exterior volume to be competitive, what can be fit inside is a definite selling point.
I believe a lot of television manufacturers already offer the equivalent of that as "commercial TVs" or "digital signage" they are marketed toward businesses. I think they're typically more expensive because they don't collect and sell data to subsidize cost, but that might be what you're looking for. Here's an example of a Samsung digital signage TV https://www.samsung.com/us/business/products/displays/4k-uhd...
They are more expensive because they generally have higher quality components and are not made to be disposable, and commercial applications have a higher price tolerance than consumers.
Despite the common trope, "selling data" doesn't lower the price of consumer devices. You only see price-less-than-cost plays when companies are trying to buy market share (think Alexa, Google Home, early Kindle, etc).
Umm, no - this is not just a 'common trope'. The CTO of Vizio has stated in multiple interviews that removing the data collection capabilities of their TVs would increase the prices. Direct quote:
"The greater strategy is I really don't need to make money off of the TV. I need to cover my cost."
and
"It's not just about data collection. It's about post-purchase monetization of the TV."
Right, but the value of the data pulled from a single TV is probably around $10/yr (how could it be higher?). Over 10 years that’s $100 - sure - but do people keep Vizio TVs around that long?
Doesn't a monthly fee mean you'll require users to sign in? In the purest sense that's tracking, you're just promising to immediately forget all of the correlations you're making between users and queries. I think you'd need a privacy policy/payment contract that adds a liability to the business to maintain privacy for users to trust that you aren't and wont track them.
It looks the info you want is in at least each of first 4 results on ddg. Specifically the 1st ddg result for me is a stackoverflow post with the question showing how to pass individual arguments and the answers explaining how to pass a variable number of arguments. (https://stackoverflow.com/questions/3811345/how-to-pass-all-...) I would say ddg gave better results.
I'm not a parent, so just speculating wildly, but there's a good chance your 3 year old has already cost more that $1750. Also, having met a few in my extended family I would doubt that a 3 year old not from London would actually know the time there, even if they could properly disambiguate the question. The phone seems like good value by that comparison
I certainly prefer DDG here. There is no ambiguity in "11:00 EST to UTC". EST is always UTC - 5, EDT is always UTC - 4, and ET could mean either depending on the time of the year. Google isn't making an arbitrary decision to deal with ambiguity it's ignoring the specificity in the query and reinterpreting it (as ET rather than EST)
If this was swapped in shipping it could potentially just work as expected while exfiltrating data whenever it could connect to the internet, potentially through builtin lte, etc.