News for hackers. Stuff that matters.
Re:How Google is forcing us to make our open source VoIP app... by kazinator on Thursday October 20, 2022 @07:52PM (#33282412)
Of course Google isn't going to look at the code. Most Google App Store apps are not open source, so why would that be a workflow at all?

You have to evaluate those same deliverables that are downloaded to the user.

To be able to infer properties of the build application from the source code review, it has to be shown that the two correspond; the shipped, built version comes from the code that was reviewed.

Poring over someone's source code is a fool's errand. You will never catch everything; people find 25 year old bugs in code that have evaded all previous pairs of eyes.

Google's approach here is poor though; they created these API's and permission model and now have to backpedal on it randomly.

If you want untrusted applications to have access to Contacts, it should be done with abstract tokens that do not reveal any contact details. Each contact is represented by an object handle that provides every imaginable operation you might want to do to, with or by-means-of a contact.

It's possible to design a system whereby some contact properties (e.g. mobilePhoneNumber) are accessible, but the result of the access is an abstract object that doesn't actually reveal the content, only represents its existence. The user interface could be priviled so that, say, a text field widget can be given one of these opaque objects, and then display the actual phone number. The only way to get at it would be to have permission to take a screenshot, and then OCR it.

Re:How Google is forcing us to make our open source VoIP app... by jeremyjh on Thursday October 20, 2022 @09:35PM (#33283204)
It’s a VOIP phone - it has to actually have the number.
Re:How Google is forcing us to make our open source VoIP app... by 6510 on Thursday October 20, 2022 @10:41PM (#33283822)
Sorry if this is a dumb question but how does it use the number if it isn't uploaded?
Re:How Google is forcing us to make our open source VoIP app... by pjerem on Friday October 21, 2022 @01:05AM (#33284716)
Of course you need to tell the server the number you want to call. That’s the basis of any VoIP application.

But you don’t have to upload every contact neither you have to send any information associated with the number.

Re:How Google is forcing us to make our open source VoIP app... by heisenzombie on Friday October 21, 2022 @02:21AM (#33285114)
This seems like the crux of things. Yes, contact information is sent from your phone to the internet. Therefore they need that flag for their app. Seems things are working as intended? The app is still free to tell the user a more nuanced privacy story if they want, right?
Re:How Google is forcing us to make our open source VoIP app... by benced on Thursday October 20, 2022 @10:52PM (#33283890)
It was always funny to me reading those stories that Microsoft shares the source of windows with government officials who are worried they have NSA backdoors in a sterile environment: what on earth could you possibly spit from just reading source code? The function won’t be “postToNsa()”
Re:How Google is forcing us to make our open source VoIP app... by AlexThrowAway on Friday October 21, 2022 @04:06AM (#33285687)
>The function won’t be “postToNsa()”

How about "_NSAKEY"?

In practice Microsoft's thousands of unintentional backdoors would be indistinguishable from a small number of intentionally placed ones. Spy agencies don't even have to bother.

Re:How Google is forcing us to make our open source VoIP app... by dougk16 on Thursday October 20, 2022 @11:26PM (#33284143)
Google does some pretty surprising levels of static analysis of compiled source, particularly surrounding their API usage. There's a few examples I've run into but the first that pops to mind is when they started requiring a yes/no confirmation dialog before allowing a user to access a non-https resource through the WebView. There was no way a human was running into that on the particular app I was working on. We're not talking advanced static analysis but it's not a simple decompile and grep either.

In another case I had accidentally left some dead/debug AWS access credentials in a build and they sniffed those out too. Notable since that's not even Google-related. They had to have been looking for a particular AWS library method signature and how it was fed. I would bet on their static analysis getting more advanced, in which case it could also be used to prove that OP is using APIs/permissions in a safe manner. But of course they're not incentivized to do that.

Re:How Google is forcing us to make our open source VoIP app... by saagarjha on Friday October 21, 2022 @02:39AM (#33285200)
Google generally would have an incentive to not be up in a negative light on Hacker News if they could avoid it, no?
Re:How Google is forcing us to make our open source VoIP app... by dougk16 on Friday October 21, 2022 @02:48AM (#33285241)
Google is a vast, schizophrenic organization. They're big enough that they have different teams and internal politics fighting each other all the time. It's not a unified consciousness with consistent incentives. Even if that's a bad take, Google is constantly seen in a negative light on Hacker News. The Google hive-mind doesn't care too much.
Re:How Google is forcing us to make our open source VoIP app... by saagarjha on Friday October 21, 2022 @02:55AM (#33285287)
Incentives not being present and the company being unable to act on those incentives are very different things. Intel is incentivized to beat Apple, AMD chip performance. That they’re failing to deliver right now doesn’t mean the incentives aren’t present or that they don’t care.
Re:How Google is forcing us to make our open source VoIP app... by dougk16 on Friday October 21, 2022 @03:21AM (#33285419)
Well, yea. Living things and organizations have incentives. The implication I gleaned from your original comment was that Google's incentive to avoid bad press on HN for its App Store policies is enough that it should use its static analysis abilities "for good". We're not debating the existence of incentives. We're debating the existence of consistent/unified motivation/ability/will to satisfy those incentives. Or are we debating? After your second comment I'm not even sure the point you are trying to make.

Besides, I repeat that Google is big enough that different factions have contradictory incentives. There are people in Google that want bad Play Store press on HN. I'll leave that as a thought exercise as to how that could be true.

Re:How Google is forcing us to make our open source VoIP app... by solardev on Friday October 21, 2022 @09:12AM (#33287649)
I think Google stopped caring about their reputation long ago. It's all lock-in and advertising increases now.
Re:How Google is forcing us to make our open source VoIP app... by aasasd on Friday October 21, 2022 @10:18AM (#33288229)
I'm not sure what kind of importance you ascribe to HN, but from here outside of SF I feel like Google doesn't give a remotest shit about this gathering, and generally has the feelings sensitivity of a triceratops. Moreover, they're actively undermining power-user workflows on Android—so the attitude can in fact be measured as negative, if only by passing chance.
Re:How Google is forcing us to make our open source VoIP app... by chippiewill on Friday October 21, 2022 @06:37AM (#33286566)
Yeah, it wouldn't surprise me if their static analysis saw the contacts being fed into a native binary (which they would definitely struggle to analyse) and threw up a red flag. From that point everything is futile because no one you can actually talk to at Google is empowered to disable the flag.
Re:How Google is forcing us to make our open source VoIP app... by saagarjha on Friday October 21, 2022 @02:43AM (#33285224)
How much time did you put it your “abstract tokens” idea? Was it just something you came up with as you wrote your comment? You’re presenting it as “it’s possible to do this and here’s how” but I’m not really aware of any systems that do this in a practical manner. Out-of-process rendering is definitely a thing it’s not nearly as simple as “just render all sensitive content away from the app and this will solve all problems!”