Live data from Hacker News

Google is forcing us to make our open source VoIP app worse

voys.co.za

231–240 of 296 posts

Re: Google is forcing us to make our open source VoIP app worse

#231

Earlier quoted context omitted.

Google generally would have an incentive to not be up in a negative light on Hacker News if they could avoid it, no?

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.

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: Google is forcing us to make our open source VoIP app worse

#232

Earlier quoted context omitted.

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.

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.

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: Google is forcing us to make our open source VoIP app worse

#234

Earlier quoted context omitted.

But don't start that php session (which sets the session cookie) before the user sends login credentials.

You are allowed a session cookie if it is for the operation of a website. You don't need to ask permission to store a shopping cart or anything like that as a cookie.

I agree, it's not necessarily only login credentials, but could be a shopping cart. However, no shopping cart is needed until the user adds an item to it. Watching the shopping window doesn't need a cookie.

The typical practice seems to be to set a session-cookie unconditionally, to be able to store user-related data within that session, even if the user has not provided any such information.

Re: Google is forcing us to make our open source VoIP app worse

#235
post #203

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 ov…

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()”

>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: Google is forcing us to make our open source VoIP app worse

#236

Earlier quoted context omitted.

You are allowed a session cookie if it is for the operation of a website. You don't need to ask permission to store a shopping cart or anything like that as a cookie.

I agree, it's not necessarily only login credentials, but could be a shopping cart. However, no shopping cart is needed until the user adds an item to it. Watching the shopping window doesn't need a cookie. The typical practice seems to be to set a session-cookie unconditionally, to be able to store user-related data within that session, even if the user has not provided any such information.

Are you using that cookie for tracking or analytics?

If not then that's fine.

Re: Google is forcing us to make our open source VoIP app worse

#237
post #224
post #219

Earlier quoted context omitted.

This API exists in Android.

In many phone brands using the PICK_CONTACT intent still requires the READ_CONTACTS permission, which allows to read all contacts. There is also an issue opened for this [1] [1] https://issuetracker.google.com/issues/118400813?pli=1

Do you have a list of the affected brands?

Re: Google is forcing us to make our open source VoIP app worse

#238
post #237
post #224

Earlier quoted context omitted.

In many phone brands using the PICK_CONTACT intent still requires the READ_CONTACTS permission, which allows to read all contacts. There is also an issue opened for this [1] [1] https://issuetracker.google.com/issues/118400813?pli=1

Do you have a list of the affected brands?

I do not. I can tell you that a Xiaomi device I tested was not affected. All Samsung devices I tested as well as Realme (and therefore I assume also Oneplus and Oppo) are affected.

This issues also hints that at least 4 years ago it was an Android issue and therefore all phones were affected. A lot of users still use phones from 4 years ago that have not been updated to the latest Android version by the manufacturer.

Also, in the issue comments some commenters say that it still happens in Android 11 and Android 10 which at this point are the Android versions that the majority of users have on their phones.

So, to answer your questions in short: all brands who released phones 4 years ago and have not updated the OS with an Android version with the fix can be considered "affected brands". It is a "best case scenario" because it appears also devices with the latest updates still show the same bug (the Realme and Samsung devices I tested were all running on at least Android 10).

Re: Google is forcing us to make our open source VoIP app worse

#239

Earlier quoted context omitted.

To give the benefit of the doubt, knowing nothing else about this company: This is clearly a South African based company. GDPR and cookie may be important compliance but it's not top of the totem pole - the local South African equivalent law (POPI) is more about data processing than cookies. Plenty of sites have not updated their cookie UX for the newer regulations. I've even noticed some sites serve different forms…

It's not, it's a Dutch company

We're an international telco, with two separate local entities & local teams, that are governed by different laws. The voys.nl website most certainly has the cookie consent screen.

Re: Google is forcing us to make our open source VoIP app worse

#240

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 ov…

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…

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.
Post reply on HN