blueg3

If you use the nonnull attribute, the assertion will be optimized away.

That's AI Overview, just like it says at the top of the box.

AI Mode in that screenshot is the tab to the left of All.

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.

AIUI, this is relatively rare, and is because of DXVK on games that use old DirectX APIs.

It certainly could.

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.

Usually when people complain about Denuvo, they're talking about Denuvo Anti-Tamper, which (perhaps surprisingly) is not a rootkit.

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.

Google is mostly interested in abuse that happens beyond the scale of how many $30 phones you can buy.

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.

It's not vapor if people actually have access to it, which they do.

Most software in the world has little novelty. You don't really need the source code.

If you don't pay for it, you don't get much in the way of quota.

Earlier on (okay, until recently), Gemini CLI's quota management didn't work very well.

Antigravity tends to have better quota management behavior.

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.

This is, annoyingly, because bare noun phrases as a search term are highly correlated with an intent to buy.

You get completely different results if you search for "what is a sofa bed" instead of "sofa bed".

I say it's annoying, but it comes from real user behavior.

This feature only exists for phones with Google Play Services, so yes.

That's pedantically fair. I broke up a longer statement:

That users won't be able to install what they want and that they would need a google account to install apps

It was split up because "need a Google account to install apps" is strictly untrue, but "won't be able to install what they want" is more nuanced.

I did clearly say, "it won't work if the APK isn't signed by someone in the Google developer registry".

So, it depends on what the user wants.

If they're running certified Android; otherwise it doesn't matter.

It is only for registered developers, so of course that very much depends on the registration system.

There's a lot of misinformation here.

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.

I don't think Google is expecting anything here.

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.

If this is an acceptable solution, just run a modern uncertified Android instead.

Correctly Android users were able to install packages and now cannot.

Not only has nothing happened yet, but this is also untrue.

It is the latter. The app has to be signed, and the signer has to register "real" identity with Google. Approval of the app itself is not a part of the process.

Yes, sideloading will still be viable from known developers.

Probably malware developers will still be free from prosecution -- what moron is going to distribute malware with their own identity attached to it? But it means when the malware gets caught (which it does) you can't just roll a new APK with a different signature. You've burned a developer identity and need a new one. Those are harder to come by, and so it rate-limits malware distribution.

Given that both of these things are obviously true, it seems like a pretty obvious solution is to just have a pop up that has a install at your own risk warning whenever you install something outside of the official app store.

It is an obvious solution, and it's a good first solution. This popup already exists.

A problem in security engineering is that when people are motivated (which is easy to achieve), they will just click through warnings. That is why, for example, browsers are increasingly aggressive about SSL warnings and why modifying some of the Mac security controls make you jump through so many hoops.

The usual take on HN is take the attitude that the developer is absolved of responsibility since they provided a warning to the user. That's not helpful. Users are inundated with stupid warnings and aren't really equipped to deal with a technical message that's in between them and their current desire. They want to click the monkey or install the browser toolbar. The attitude that it's not my problem because I provided a warning they didn't understand doesn't restore the money that was stolen from them by malware.

Not only will sideloading via ADB continue to work, installing from most other third-party app stores will continue to work. The developers on the Amazon, Samsung, and Epic app stores won't have a hard time with the developer verification process. F-Droid is in a uniquely inconvenient position that they have a legitimate app store, but its design causes them to have a hard time with developer verification.

I realize F-droid has an understandably strong opinion here, but this writing is disingenuous.

From the post:

Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure. But if we reluctantly accept that “sideloading” is a term that has wriggled its way into common parlance, then we should at least use a consistent definition for it. Wikipedia’s summary definition is:

the transfer of apps from web sources that are not vendor-approved

The opening two sentences of the linked-to Wikipedia page on sideloading:

Sideloading is the process of transferring files between two local devices, in particular between a personal computer and a mobile device such as a mobile phone, smartphone, PDA, tablet, portable media player or e-reader.

Sideloading typically refers to media file transfer to a mobile device via USB, Bluetooth, WiFi or by writing to a memory card for insertion into the mobile device, but also applies to the transfer of apps from web sources that are not vendor-approved.

The phrase after the "but" in the second sentence isn't the "summary definition". It's the part of the definition that best supports your argument. Cutting the Wikipedia definition down to that part is deceptive.

Also in the post:

Regardless, the term “sideload” was coined to insinuate that there is something dark and sinister about the process, as if the user were making an end-run around safeguards that are designed to keep you protected and secure.

Immediately later in the same Wikipedia page is a paragraph that is literally about how the word was coined:

The term "sideload" was coined in the late 1990s by online storage service i-drive as an alternative means of transferring and storing computer files virtually instead of physically. In 2000, i-drive applied for a trademark on the term. Rather than initiating a traditional file "download" from a website or FTP site to their computer, a user could perform a "sideload" and have the file transferred directly into their personal storage area on the service.

That's funny. The history of how the word was coined and the post's claim about how it was coined aren't similar at all. Weird.

They hired a bunch of former Chrome engineers, so...

PayPal doesn't cost significantly more than what a small online place can get from other payment processors. It's something like 3% + $0.50. That's also not much more than what a small business can usually get for in person credit cards.

This site does use buymeacoffee.com, which appears to be a dedicated payment platform. Its transaction fee is apparently 5%, which is steeper, but better for these small donations because of the lack of a fixed fee.

Bard came out shortly after ChatGPT as a prototype of what would become Gemini-the-chatbot.

There were other, less-available prototypes prior to that.

It's MIT-licensed, so they don't have to share their changes. That'll make it harder to take their changes.