dataflow

I don't really understand the choices. Is a laptop that is normally docked on a desk considered a desktop for the purposes of your question?

That sounds awful. This kind of case doesn't seem like something you should let a single person decide on their own, judge or not. Is she not entitled to a jury trial because it's a misdemeanor or something? If she can find the funds/support somehow it totally seems worth appealing all the way to the supreme court.

> after 1986

Ideally an offline copy that can be made read-only with a physical switch. So that when you're trying to restore, you know nothing is going to mess with it. Not sure what the right solution is for something like that.

No, all you're showing in that example is that a pointer is passed as part of the ABI. You're not showing that RVO relates to that in any way whatsoever. If you write the same function in a manner that (N)RVO can't kick in, does the pointer no longer get passed?

The reason this should sound dubious is that you're suggesting the caller needs to know the callee's body in order to know how to call it, but it should be possible for the two to be compiled entirely independently, and in fact mutual recursions should be fine too. After all, the callee knows where the return value has to land either way, and the caller similarly knows where to expect it, regardless of when/how the object is constructed or destroyed.

The point of (N)RVO is to directly construct the return value in-place at the calling frame. Which requires knowing what object will land there.

In RVO there is no problem because you know what object is the one you need to put there.

In NRVO there is a problem because you might have one of multiple objects being returned and you need to know which one to construct at the call site; it can't be all of them on top of each other. But you don't necessarily know at the time of construction whether that object will be the one that is actually returned. Doing so requires imperfect code analysis so the standard would need to define the complicated analyses to perform.

> N/RVO works by (at the machine language level, of course) rewriting the function signature to return void and take an extra pointer parameter

This sounds wrong, are you sure? Would you mind demonstrating with an example on godbolt? Whether NRVO applies or not, the ABI should be the same, AFAIK.

Just wanted to amend this to note that what I wrote also applies to the war against ownership, etc... I'm making no attempt to be exhaustive here, just trying to get a larger point across.

I'm pretty sure they could support this if they wanted to, which implies they don't want such transactions. And they obviously aren't going to make it easy to get around something they don't want. So we agree on that. It sucks. I'm not debating any of that. I think our only disagreement is on whether the policy is clear, and AFAICT it is, as terrible as it might be.

> If you can't use their systems for a donation with a sales tax rate of 0%, then per the policy that means you can route users to alternative payment methods for those transactions. So by your reasoning, if donations to OSC are not subject to sales tax, then what the app is doing should be okay.

I'm not seeing "if not {this}... then {that}" implication anywhere that you're citing. i.e. I do not see anything that implies at least one of the billing systems must be permitted for any given app. All I'm seeing are some sets of conditions under which you can use Google's payment system, and other sets of conditions under which you can use an alternative billing system. Sometimes they overlap and sometimes neither applies.

What's clear to me is:

- Page [1] says that you can't use their billing systems for "tax-exempt donations" (however that is supposed to be interpreted).

- Google's last correspondence says "For more information about alternative billing and external linking options available in some countries and regions, see the FAQ", and does not claim that such options are (or aren't) available to them. Page [2] says that this varies by country, and it's not clear to me what countries apply to them, but they seem to be in Japan. I am unclear on what they have/haven't done here, but it sounds like they have not followed all the requirements in [3] (or whatever the relevant requirements are), as [1] says: "Developers serving users in eligible countries/regions may offer users an alternative billing system within the app if they enroll in the applicable program and agree to the additional terms and program requirements."

I'm not sure if you have more information beyond this, but that's all I'm taking away so far. Perhaps I'm missing something?

And obligatory disclaimer (because this is HN): none of this is to suggest I like these circumstances; I'm just discussing the facts as I see them written.

[1] https://support.google.com/googleplay/android-developer/answ...

[2] https://support.google.com/googleplay/android-developer/topi...

[3] https://support.google.com/googleplay/android-developer/answ...

So I'm only a layperson and don't know what is strictly legally required, but my understanding (based on reading/third-hand information) is that payment processors do in practice end up with more work to do for this, whatever the reason. Quoting from [1]:

> Nonprofits have strict tax regulations when accepting donations. The more a payment processing system can assist with these regulations, the better for you and your donors. For instance, donors need to receive specific documentation for tax-deductible contributions, such as donation receipts. Additionally, different types of donations may involve different tax considerations for the donor and the organization. Nonprofits also have to consider any state and federal regulations regarding their charitable solicitation and fundraising activities, which may vary depending on location and activities.

And there's of course also exemption from sales tax which they have to handle too.

[1] https://www.subsplash.com/blog/nonprofit-payment-processing#...

> So you DO know what's going on! In that case I have no idea why you're arguing in favor of having a gate placed in front of our [personal, owned] phones to regulate what we do with our own devices.

Then you're not understanding anything I'm writing, and I don't have the energy to keep going.

All I'm saying is that you need to pick your battles carefully and be honest about your goals if you want to have a fighting chance of winning this war against general-purpose computing. I want to win this just as much as you. I don't want to lose it, and I certainly don't want to lose it in a dumb way. Dying on the wrong hill during the wrong battle because people on my side constantly lie, exaggerate, and otherwise misrepresent reality and turn away would-be supporters is probably the dumbest way to see this happen, and it should make you angry, if you actually want some success in what you're doing.

I will leave you with https://queue.acm.org/detail.cfm?id=3818307.

This is the stock OS you paid for. It's beholden to Google and subject to their updates as it always was. You can either flash a different OS entirely, or even break their ability to update it before the change rolls out, if that's what you want. What I think you really want is to pick and choose what updates you get, which I would love too, but that's neither here nor there.

I agree wholeheartedly, but you can already unlock and root your phone and install whatever you want. This is not that battle. Mind you, I don't like either of these, but they're very different in nature.

> Personally for me, a fake convoluted opt-out is the same as no opt out so we're already there.

Convoluted, yes, but fake? Aren't you just repeating the same lie? That means it looks like it bypasses the verification but doesn't actually do so. What are you basing that off of?

The mere fact that they have to avoid dealing with sales tax here (unlike their typical transactions) is clearly extra complication for them. So you can understand that sales tax being 0% (thus "not taxable") can make things harder, not easier.

Having to deal with bookkeeping or paperwork for tax deductions could also make things harder.

In any case, whether you think these are easier or harder, and regardless of which cases should be supported from a business perspective, their policy page (at least the one that I'm reading) very clearly says you can't use their system for such donations.

> What would be "really bad" for you?

"Block[ing] every Android app whose developer hasn't registered with Google, signed their contract, paid up, and handed over government ID. Every app and every device, worldwide, with no opt-out"

...would be "really bad" in my view.

Which is probably exactly why they worded it that way, despite knowing fully well they are (rather blatantly) lying. They literally explained how to avoid it themselves further down below, after you've already been angered.

> Aren't donations untaxed?

I don't know every jurisdiction, but that's not the only relevant factor. If they are tax-deductible, they still introduce the need for paperwork etc. for the payment processor to let the payer deduct it from their own income. A 0% tax on some action doesn't imply you don't have to worry about tax law when performing said action.

Though I think you can just read the policy and take it at face value and not even have to know any of this beforehand.

I didn't say it's a question of sales tax collections. I said a payment processor deals with sales taxes.

In this case they clearly have to exempt this transaction from sales tax in order to support it, when other transactions through their system do get sale tax applied. So the mere fact that they have to deal with sales taxes in general is likely to introduce additional complications for them even here, in cases where sales tax turns out not to be applicable.

> Things are really bad already on Android. Most bootloaders are locked, Google prevents you to use the very few unlocked ones through the (legally questionable) Play Integrity. AOSP is basically dead

This feels like complaining about the color of the bikeshed, me saying you should save your complaints for when things get really bad, and you replying "things are really bad already, there is a rotten carcass in there and the roof leaks."

Okay, so let's keep complaining about the color then.

Their emails are confusing, but they came after the alleged violation in private communication, not what you were going from at the time of the alleged violation. If you ignore them momentarily (surely you understand they probably aren't as well-scrutinized by lawyers, which would explain why they appear to mistakenly refer to the tax status of the recipient rather than that of the donation), is anything else actually confusing or inconsistent? Their policies, the relevant laws, and what common sense would have you expect - they seem pretty cut and dried. Are they inconsistent with anything other than their emails, which came after the fact?

From another angle: why/how do you feel the tax-exempt-mess of the recipient itself could sensibly be the determining factor here, rather than the taxability of the transaction itself? Is there any law or precedent or anything outside their emails that would suggests a payment processor should look at the tax status of the recipient rather than that of a transaction?

> On what planet do you think anyone other than the most dedicated of dedicated people would choose the shop that requires waiting a whole day to use it when the alternative has no such restriction?

I have no clue what you're referring to or worried about here, could you clarify? Are you worried Android is going to lose power users to iPhone? What are the alternative shops you're referring to here? We're not buying pastries.

> The developers in F-Droid are verified, just not by Google.

"Unverified" in my comment was a shorthand for "unverified by Google", not an insult.

> Google is not the be-all and end-all, but with this power-play, they are making themselves that.

The complain about that? Rather than wasting time complaining about the 24h wait?

I don't know if people's imaginations are lacking here, but there could easily be a world in which your 'alternative' verifier would still make you wait 24h (or longer). The wait is clearly a security mechanism, regardless of who makes you do it. (And yes, it could have been chosen for plausible deniability.) Is your actual problem the wait itself, or is your actual problem the identity of the entity making you do it, or is your actual problem that the power is too concentrated in one entity, regardless of the entity? These are very different issues with very different solutions.

> And for some reason you seem to think it is reasonable to assume it is going to stop here?

I really don't. That is, actually, my entire point: people are going to roll their eyes at this right now. And then you're going to lack/lose the supporters you'll need when things really get bad.

> I'm guessing you've never shown up to a foreign country without a phone. First thing I do after I get through customs is find the phone store.

Indeed I have not. In fact I haven't even heard of people doing this until your comment. And that's before unknown app developers coming into the picture. I assume you do this to avoid border phone searches? And you feel the (ostensibly) security-related mechanisms for the rest of the world to be centered around this use case? Meaning the rest of the world should pay the cost to their own security to cater to this flow?

> Google's "escape hatch" is a trap door

>> Wait 24 hours

>> Pick "allow temporarily" (7 days) or "allow indefinitely

Geez. I don't like what they're doing either but this fear-mongering is not helping your cause. So the "trap door" here is just that you can't buy a phone and immediately start loading apps from unverified developers onto it until 24h have passed? Of all the hills we could be dying on, that's the one we're picking?

> Play billing "must not be used in cases where payments include … tax exempt donations"

> Note: 501(c)(6) is a tax-exempt status; donations are not tax-deductible for the donor. Google's communications explicitly state "tax-exempt".

Isn't it pretty obvious that the problem is the donations aren't tax-exempt, despite the organization being tax-exempt? Your note suggests you already understand this.

Logically, the payment processor (who deals with sales taxes rather than income taxes) should worry about the taxability of the transaction rather than the tax status of the recipient, right?

> Specifically, your app allows users to contribute donations to an organization that is not tax-exempt.

So whoever is writing their email is mixing these two up, but you're reading the policy itself and it is fairly clear-cut what it means for you, right?

Note that that might just be because he doesn't want to say something that might lose supporters, not because he would actually do nothing. (I'm not saying he would definitely do something, just that what he does or doesn't say about it right now doesn't indicate much.)

I don't understand what's ridiculous about that pip CVE, could you explain? Just because something is by design that doesn't mean it's not a vulnerability or somehow unexploitable.

I can't speak for your imagination, but this absolutely does come up if you're writing high-performance code.

Also note that being able to access arbitrary objects (as opposed to objects in the same array) requires storing two pieces of information: an index and a pointer to the beginning of the array. So it can use twice as much memory, which affects your cache etc., though you don't even need that to see the effect.

Probably because most of the time you list branches you goal isn't to discover what exists, but to find the specific one you're looking for.