The term has kind of degraded, because people started marketing that "end-to-end encryption" is the "right" answer.
Encryption in transit means that network intermediates can't read the data. The two endpoints of the network communication can.
E2E encryption is more context-sensitive, and its context mostly comes from messaging. It means that the data is encrypted and that operational intermediates cannot read it. So in the context of messaging, the servers that run the messaging system cannot read the messages. Or, for an email, only the sender and recipient, not any of the intermediate email servers.
There's a big difference -- you can't really control or predict your network intermediates, but you can in theory know the operational intermediates. Whether something is E2E encrypted often depends on what intermediates you bring in to scope.
For example:
> That means that an Oura user's health data can be unscrambled at certain points as it travels from a person's ring, through their phone app, over the internet, and as it lands on Oura's servers.
If the ring uses Bluetooth to sync the data to your phone and the phone syncs data to the Oura servers, but the data is in the clear on your phone, then by this definition, it is not E2E encrypted. However, that's a pretty reasonable setup, depending on how the data on the phone is stored.
Buying a better GPU improves your graphics performance and that's basically unrelated to the area where a sandbox impacts performance.
Killing your web browser is probably just lowering memory pressure?
Sandboxes add overhead to syscalls. It's kind of similar to running under Wine, which also adds significant syscalls overhead. Wine also has a much more impactful DirectX translation layer, so your sandbox performance would be probably be much better than the Wine performance.
Only a relatively small (but popular) subset of games use anticheat. Most games -- including the one in this article -- could theoretically run in a sandbox.
They said "capable of Play Integrity attestation". It's a weasel statement. If you have GMS, you're capable of performing PIA attestation, you just might fail. So it's strictly true, but doesn't tell us anything about whether it requires PIA.
While I get that there a lot of ads -- particularly if you search for something with the intent to buy -- I tried out both of your example queries.
"sofa beds":
Popular Products section (5x2 grid of chips)
Reddit link: "Are sofa beds actually practical"
Wayfair
Reddit link: recommendations
Wirecutter
"Discussions and forums" section (Reddit and random crap)
Ikea
"In stores nearby" (5x1 of chips)
"Deals on sleeper sofas" (5x2 of chips)
"Things to know" section
"Brands" (one row of chips)
Furniture store
Furniture store
Furniture store
"More products" (5x2 chips)
Furniture store
"People also search for"
None of these were marked as sponsored. I assume, but don't know, that the Popular Products chips are sponsored somehow.
"hard drive":
Popular Products (5x2)
Wikipedia
Best Buy
People Also Ask section
Reddit: request for what brand is good
Brand Picks for You (5x1)
Things to Know section
Amazon link
PCMag reviews
Reddit: "What exactly is HDD?"
Brands section
NYT review article
What People Are Saying section (a weird mix of stuff)
Wikipedia
More Products section
Store link
People Also Search For section
None marked as sponsored.
Not that crazy for a vague, commercially-oriented search. Certainly not 100% ads.
> I guess it means the Play store will be the only way to install an app
No, non-Play stores will still work, but developers will need to register a developer account with Google that is tied to some real identity. They already need to do this to distribute through the Play store, but now it'll apply regardless.
This is to make it harder for scam apps to churn app signatures. Kind of like requiring code-signing, but with only one CA.
> That users won't be able to install what they want
No, sideloading will still work, but it won't work if the APK isn't signed by someone in the Google developer registry.
> and that they would need a google account to install apps
Nope.
> That app developers have to go through google to distribute their apps, with identity verification etc.
They don't need to distribute through Google, but they will need to be involved with Google and do identity verification.
> However, I'm also reading here and there that it is a threat to alternative ROMs. To me it sounds at the contrary as an amazing opportunity, as they can strip this verification and be the only truly open Android, or am I missing something?
You're being misinformed. They won't even need to strip the verification. The verification is only for certified Android -- OEMs that partner with Google. Custom ROMs and the OEMs that aren't certified (Amazon, some Chinese manufacturers) won't have verification.
The target audience for verification and who would ever use a custom ROM has basically zero overlap.
A Gemini query uses about a kilojoule. The brain runs at 20 W (though the whole human costs 100 W). So, the human is less energy if you can get it done in under 50 seconds.
In my experience, people don't really care about rooted devices and non-stock Android -- if those devices are actually phones in the hands of human users.
The big fraud vector is running emulators in datacenters or skipping running the app entirely and talking directly to endpoints. Requiring that an entity making a request is from a real phone and is from (approximately) your app adds friction and is effective at reducing fraud.
They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.
The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.
It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.
The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.