[HN Gopher] Google is forcing us to make our open source VoIP ap...
___________________________________________________________________
Google is forcing us to make our open source VoIP app worse
Author : DevhouseSpindle
Score : 362 points
Date : 2022-10-20 11:45 UTC (11 hours ago)
(HTM) web link (www.voys.co.za)
(TXT) w3m dump (www.voys.co.za)
| j45 wrote:
| With Rust and WA emerging it will be interesting to see how long
| it takes to get a voip client as a PWA that just runs in the
| browser.
|
| WebOS when with Palm was ahead of it's time from a software
| perspective and couldn't get the hardware out. The ability for
| all apps to be JS/HTML only with WebOS would be super
| interesting.
| jeroenhd wrote:
| To get that to work, you'd need to run some kind of WebRTC-to-
| SIP proxy which would be abused to hell and back.
|
| There seems to be an abandoned open source project that you can
| use to do this: https://github.com/saycel/Saycel.Phone
|
| 3cx also seems to have built a web app for their SIP product:
| https://www.3cx.com/blog/releases/web-client-pwa/
|
| No need to get Rust or WASM involved. Built-in browser support
| should allow you to do this stuff with just Javascript.
| grishka wrote:
| Thankfully the use of Google Play is not mandatory. You could as
| well distribute your app from your website and make it update
| itself -- you know, just like people did for ages with desktop
| software.
| turminal wrote:
| Yeah, good luck with that. Nearly nobody installs apps from
| outside Google Play.
| naikrovek wrote:
| that's not exactly true, though of course I don't have
| numbers.
|
| maybe that is something you just don't see a lot, but that
| happens often?
| mixedCase wrote:
| Look up the Epic/Fortnite situation and the only conclusion
| from its development and Epic's decisions is that it almost
| _never_ happens and unless your market is exclusively
| techies you 'd be foolish to consider it viable as your
| sole release channel.
| grishka wrote:
| Huh? One example: everyone did sideload Pokemon Go in 2016
| because its availability on Google Play was very limited for
| a very long time.
| tourist2d wrote:
| So why didn't Pokemon Go pull out of Google Play? Your only
| example is from 6 year and keep the 30% which Google takes?
| You only have one example from 6 years ago and people only
| sideloaded there only because it wasn't available on Google
| Play.
|
| The one example you provided proves the opposite of what
| you wanted lol
| ziddoap wrote:
| I'm not familiar with mobile app review process, would _any_
| change in code require a re-review /re-submit? If Google approved
| it as-is, could the developers add a few lines as an "update" and
| skip over the full review process?
|
| Seems like the ruling is being made on what _can_ be done with
| the current permissions, rather than what _is_ being done. If
| that 's the case, I sympathize with the devs but I think I
| support the position Google is taking there.
|
| Off-topic comment: I use NoScript, and the entire text of the
| article renders for a half second before disappearing and for
| some inexplicable reason requiring JS to be enabled. If you can
| render it for that half second, why hide it? Why force me to use
| JS when you just proved that you can render it without?
| Marsymars wrote:
| > I'm not familiar with mobile app review process, would any
| change in code require a re-review/re-submit?
|
| Yes.
| jsnell wrote:
| It does sound like they're batch-copying the entire contact
| book into their app at startup, rather than using the Android
| contact picker. The static analysis problem of determining
| whether there is / isn't a batch import seems a lot easier than
| determining with certainty what happens with the contacts after
| they were saved to disk.
|
| Though the article doesn't actually show any screenshots from
| the review emails, but just paraphrases them, so we don't even
| know that their interpretation of the rejection reason is
| correct.
| TheNorthman wrote:
| This could, of course, be an explanation. Except for the
| _stated fact_ that after they removed the batch import, they
| were still rejected.
| jefftk wrote:
| I don't see where they say they removed batch import? Just
| that they removed caching. I don't think they're using the
| default contact picker?
| exprez135 wrote:
| Re: the off-topic comment: Same here, but I noticed that
| Firefox's reader button was still appearing. I was able to read
| with that without loading the scripts after all.
| londons_explore wrote:
| The code review is done 'black box' - ie. the reviewer doesn't
| have access to the code.
|
| All the reviewer can see is what permissions the app has. They
| see internet permission and contacts permission, and have to
| assume that evil code might be uploading the contacts to the
| internet.
|
| There isn't really any other way to do it - even a thorough
| code audit (a process that would take months for just a single
| app) would be unlikely to uncover a well hidden flaw that is
| intended to allow an evil app developer to steal contacts of
| users only after the app passes the review process.
| capitalsigma wrote:
| It seems most likely that there is some static analysis being
| done to the binary here, or maybe some instrumented JVM that
| "poisons" bytes that come from the contact list and traces
| them to see if they ever land on disk or sent on the network.
| Clearly Google doesn't ban every app with that combination of
| permissions.
| dspillett wrote:
| This sort of thing is why I intend to never write a mobile app
| for Google/Apple/other devices.
|
| Though as I never get around to writing my many desktop or web-
| based app ideas, maybe this isn't much of a problem for
| Google/Apple/other!
| webmobdev wrote:
| Yeah. I bought a Mac, an iPad and an iPhone to do mobile
| development for ios. And then I realised how screwed up and
| exploitive the whole Apple ecosystem is for developers - they
| not only want us to pay them annually for the "privilege" of
| developing on their platform (even though we add value to their
| platform by creating software for it), but they also want to
| charge us a commission on each sale (with the bar that we can't
| tell our customers that the price is higher because of the
| "Apple Tax"). I decided not to support their platform. And
| after reading many tales of developers struggle with the
| illogical bureaucracy of the "app stores", I feel that I made
| the right decision.
|
| I understand the Google ecosystem is similar, but slightly more
| bearable because Android allows side-loading. Waiting for the
| day when legislation / regulation upholds our consumer and
| computing rights to develop, install and run software on our
| own devices without ever needing permission from the device
| makers.
| pedro2 wrote:
| Never? Unless you give up on NFC, banking apps and all those
| goodies.
| arsome wrote:
| We've had NFC, banking, etc on rooted phones and even on
| windows desktops loaded with malware for decades now.
| Clearly there's a tradeoff that can be made here and the
| banks still find it worthwhile to offer the extra features
| and save money on staff even if it occasionally causes
| fraud.
| pedro2 wrote:
| Yes but it is troublesome and AFAIK getting more
| difficult each year.
| dspillett wrote:
| _> Never?_
|
| As the post you directly responded to never said the word
| never, I'm thinking you where actually responding to the
| previous comment. In which case: yes, never.
|
| _> Unless you give up on_
|
| I don't refuse to _install_ apps, I have apps for both my
| primary banking organisations on my phone, I don 't intend
| to _write_ apps, I don 't intend to provide extra fodder
| for their platforms and claims of their size. Most apps
| don't need the things that not being a native app means
| they can not support. NFC there might be uses for, but not
| that are irreplaceable that I can immediately think of, and
| you can access things like the phone's camera so other
| features like NFC might happen in that realm too.
| charcircuit wrote:
| iOS allows sideloading too. Also just because Apple gains
| value from developers, the developers also gain value. It's a
| mutually beneficial relationship.
| grishka wrote:
| It is not real sideloading though. Any app that iOS
| installs needs to be signed with an Apple-issued
| certificate. You can't install an app on your iOS device
| without Apple involvement.
| grishka wrote:
| Android is not Google.
| dspillett wrote:
| They do control the default app repository, so from the PoV
| of many users, at least with respect to apps, the two are
| pretty much equivalent.
| grishka wrote:
| There are Android phones sold at least in Russia without
| Google services at all. People use them mostly fine.
|
| And no, it's not mandatory for developers to use Google
| Play. It's a bit more work to DIY your app distribution,
| but you get total independence in exchange. It's
| ultimately developer's choice to make.
| pomatic wrote:
| I was intrigued by the prospect of a foss voip phone app that's
| cross platform - but was unable to find the repo. for the app
| (libary repos are available and obvious, just not the app as a
| whole). Anyone know where it lives?
| captainzidgel wrote:
| The website calls it the Voys app but I think it's actually
| called Vialer: https://github.com/open-voip-alliance/vialer
| It's the only full app in their repo and it fits the
| description they gave on the website.
| csdvrx wrote:
| Does it work with twilio sip trunking?
| pwg wrote:
| Does Linphone (https://linphone.org/) not meet that need of
| cross platform (website claims versions for all major OS'es)
| and open source
| (https://gitlab.linphone.org/BC/public/linphone-desktop)?
| duxup wrote:
| Personally I would associate access to my contacts with the
| ability to just upload it.
|
| No reason version 2 can't do the thing after they upgrade and I
| already gave permission in version 1.
| psykus wrote:
| Is Google seriously just run by AI at this point? I imagine at
| some point up the middle management chain it's just a layer of AI
| making decisions that no one has the authority to override.
|
| Similar to how Amazon warehouse workers say that they're working
| for an algorithm at this point making hiring/firing decisions.
| kaushikc wrote:
| Amazon runs on hire quickly and fire quickly policy (many other
| businesses have already copied this style of recruitment),
| which is why they are finding themselves running out of massive
| pools of workers.
| yazzku wrote:
| Two companies should not decide what goes in and out of the
| mobile ecosystem, or we need to stop non-standard and proprietary
| ecosystems from becoming a social norm and building
| infrastructure on top of them.
| sophacles wrote:
| > Dear Google. We are one of the most privacy-conscious companies
| you can find.
|
| I think I found the reason Google is rejecting your app.
| chunk_waffle wrote:
| If this is at all like the Chrome Extension review process,
| having a privacy policy that is clearly written and describes
| that you don't upload any contact info (as well as what info you
| do upload) might go a long way.
| dima_vm wrote:
| From my past experience, both Google and Apple fervently defend
| their built-in caller app, and really-really don't like any other
| app making regular voice calls. Part of that is that they don't
| want cloning (they clearly state that your caller app must look
| obviously different from default system one), which is
| understandable, but even when it clearly not a clone, they make
| take it pretty hard, it feels like they would rather just ban it.
| bombcar wrote:
| Fun fact, almost all VOIP in the USA comes through Bandwidth.com
| https://www.bandwidth.com/voice/voip-origination/
| dna_polymerase wrote:
| Why do they need to cache contacts 'locally'. Are they usually
| stored in the cloud?
| r_hoods_ghost wrote:
| Ahh a privacy oriented company, that won't allow you to opt out
| of their analytic cookies this breaking the law in the EU. Or in
| other words, not privacy oriented at all.
| enriquec wrote:
| europe's cookie fiasco is so idiotic - why don't you just
| disable them in your browser if you care?
| Nextgrid wrote:
| Because the EU knows that you don't need cookies or client
| cooperation to track people as there is enough information
| the client sends (and _has_ to send for functional purposes -
| think IP address, user-agent, browser fingerprint) to
| reidentify it down the line even without a persistent
| identifier.
|
| If you think clearing cookies will defuse industrial-scale
| spyware from the likes of Facebook, Google or the various
| data brokers:
|
| 1) Don't waste your time clearing them; modern browsers
| already heavily restrict third-party cookie access and clear
| them on their own
|
| 2) I have a bridge to sell you
| atriix wrote:
| the irony of that, is that all to many times, one must enable
| cookies to be able to dismiss the, often full screen
| takeover, cookie notice to "disable" cookies
| Nextgrid wrote:
| Non-compliant & dumb implementations doesn't mean the law
| itself is bad. The problem is a major lack of enforcement.
| gunapologist99 wrote:
| A lack of enforcement is definitely not _the_ problem.
|
| Stated as the inverse, what would _more_ enforcement
| solve?
|
| And, even if it was a solution, what would this
| additional enforcement actually enforce? A poorly written
| law, apparently designed to introduce additional friction
| into simple web browsing, with porous and easily-evaded
| definitions and vague goals that only apply to a tiny
| fraction of planetary inhabitants? (Because that seems to
| be the actual problem.)
| Nextgrid wrote:
| More enforcement will force businesses to remove
| obnoxious consent flows as those are already in breach of
| the regulation and it just needs enforcement. Consent
| should be explicitly opt-in, you can't force it with
| annoyances, dark patterns or denying the service.
|
| Some shitty businesses who outright can't be profitable
| without stalking will fold which is a good thing (less
| spyware in the world), most will adapt just fine -
| executives/shareholders may just have to forego that new
| yacht or supercar.
|
| > A poorly written law, apparently designed to introduce
| additional friction into simple web browsing
|
| It's not poorly written. It's written very well to
| explicitly outlaw the kind of malicious pseudo-compliance
| you're complaining about. Its objective is not to
| introduce friction, it's to outlaw spyware (which we've
| somehow normalized over the past decade).
|
| > with porous and easily-evaded definitions and vague
| goals
|
| The goals are not porous - in fact the law is
| intentionally broad enough so that the _spirit_ of any
| data collection /processing can be taken into account,
| rather than a specific technicality (which is why
| focusing on _cookies_ is stupid because GDPR doesn 't
| care whether you do your tracking with cookies, IP
| addresses or the shipping/billing address your customer
| provides). The goal of the law is again to outlaw the
| business model of spyware.
|
| > a tiny fraction of planetary inhabitants
|
| Is the EU _that_ small? Come on.
| orangecat wrote:
| _Its objective is not to introduce friction, it 's to
| outlaw spyware_
|
| Then why not just outlaw the spyware? Why go through the
| theater of "you can use spyware, but you have to get the
| user to 'agree' to it first, and you're not allowed to
| offer them anything in exchange"? That's just asking for
| the dark patterns and malicious compliance/non-compliance
| that we've gotten.
| Nextgrid wrote:
| > Then why not just outlaw the spyware?
|
| The spyware _is_ outlawed, and so is coercing users into
| "agreeing" with it.
|
| The problem is that neither restriction is adequately
| punished to deter the behavior; as of right now, you're
| better off profiting off spyware because even _if_ you
| get caught (which is a very big _if_ ), the penalty is
| merely to ask you to stop doing so (and future compliance
| isn't monitored, so you can get back to your usual
| shenanigans once the dust settles).
|
| From a GDPR perspective, it doesn't matter whether you
| don't ask for consent or coerce users into it - both are
| outlawed, however, because of lax enforcement, an
| industry of snake oil has developed to sell companies
| non-compliant solutions (because _actual_ compliance
| would put them out of business), along with spreading
| falsehoods and misinformation to promote said business
| which is blatantly visible on this very thread.
|
| If you truly want to comply with the GDPR, the answer is
| to rethink your business model and fire a lot of people.
| But since it's uncomfortable, everyone would rather
| _pretend_ they comply by paying for an expensive, not-
| actually-compliant "consent management platform" and
| otherwise continuing as usual.
| croes wrote:
| Because there wanted cookies and unwanted cookies.
|
| Websites could store my decision to disallow tracking
| cookies, but somehow they don't do that.
|
| So it's not a european fiasco but website malice.
| Nifty3929 wrote:
| At the risk of stating the obvious, developers are not the
| customers. Android has millions of customers who benefit from
| Google's attempt to prevent misuse and abuse. It is far from
| perfect - but a bias toward protecting the end-user and their
| data is the correct choice.
|
| In this case, there is a "false positive" where Google thinks
| something bad is happening when it isn't. They see that contacts
| are being touched, but they don't know what is being done with
| that data and assume the worst (as they should).
|
| It would be nice if the accuracy could be dialed-up by inspecting
| code or other manual processes, but this is labor intensive and
| therefore expensive for society as a whole, regardless of who
| pays the price (devs, Google, or users).
|
| Question for Voys: If there was a service where for $10k/yr you
| had a white-glove app-approval service from Google/Android/Play
| where they do actually inspect your code, would you pay for it?
| Maybe you would, and maybe there's a good market there. I don't
| know.
| nnopepe wrote:
| Given that their site thinks itself above GDPR I'm inclined to
| believe google
| zbuf wrote:
| Can you be more specific?
| godshatter wrote:
| Can they put it on f-droid and point their users there? Downside
| is that users don't know what f-droid is and have to install it,
| upside is they find a new "app store" that has some new techy
| things on it. Not sure if f-droid gets around having to tell your
| phone it can run third-party apps, but if it does that would be a
| win as well.
|
| I didn't see in the post if they sell this or give it away.
| danuker wrote:
| Completely open source means no place for supposedly secret
| Firebase Messaging credentials, which requires developers to
| bend over backwards, if they want reasonably quick
| notifications:
|
| https://github.com/deltachat/deltachat-android/issues/82
| z3t4 wrote:
| Just release the apk from your website
| jasonjayr wrote:
| IIRC, if they attempt to 'hack' this by falsely claiming they are
| uploading the contacts, they might be on the hook in the future
| if Google expands the scope of their mandatory pentests:
|
| https://cloud.google.com/blog/products/g-suite/elevating-use...
| squarefoot wrote:
| The mobile ecosystem has been built with the sole intent of
| milking users through targeted advertising, media consumption and
| unnecessary services subscription, so I find normal that
| corporations behind the OSes fight hard to maintain the platform
| as closed as possible (proprietary or seemingly open OSes, closed
| drivers, locked bootloaders etc). Their deepest fear is seeing
| their ecosystem conquered by Open Source, or for that matter any
| other kind of scenario (shareware, donationware, etc) in which
| users and developers are directly in contact and no middleman is
| necessary anymore.
| duxup wrote:
| I fear we as users have been trained as well and perpetuate it.
| People generally don't want to pay, so we're the product,
| advertising pays ... the whole ecosystem is a mess.
| LtWorf wrote:
| It doesn't matter if you want to pay or not. These companies
| need to make more money than they did the previous quarter.
| So they need to always find new way to exploit continuously.
| duxup wrote:
| Plenty of apps and services are happy to take money and
| have no advertising and etc.
| somat wrote:
| This is why I say a little prayer of thanks to the internet
| elders every day that the internet was developed in academia.
|
| I mean sure it is a hive of villinary full of corperate
| scumbags trying their hardest to steal your freedoms and make
| you into the perfect consumer. but when I think about how much
| worse it would be if it had been developed commercially I get
| this feeling of overwhelming dread and have to go lie down for
| a while.
| Andrex wrote:
| Oh man, you should have seen the mobile sphere _before_
| Android...
| acdha wrote:
| Before iOS, to be fair. Touchscreens got the attention but
| the use of the iPod's popularity to negotiate a non-terrible
| cellular market was equally transformative. The carriers used
| to charge something on the order of $50k each to be listed in
| their app stores and their percentage of revenue was high and
| negotiated based on your perceived ability to pay: we had
| several clients bail on J2ME projects because they were being
| asked to take home less than half of each sale and making 6-7
| figure minimum profit commitments to each carrier! The sales
| person would look at their total corporate revenue to base
| their first offer on, and they were not quick to negotiate
| down to our actual budget.
| sangnoir wrote:
| > Before iOS, to be fair.
|
| iOS didn't move the needle on open source, open bootloaders
| or anything gp mentioned. All iOS did was shift the balance
| of power from telecom companies to Apple.
|
| Android was _far_ more open than all that came before it:
| the source code was available,it used open source &
| contributed back, and brought a very "PC" mindset[1] to an
| industry that had always considered handsets to be
| appliances (save a few Nokia models in the Communicator
| line).
|
| 1. "Intents" that could be handled by any app of the users
| choosing was very much like "Open with..." on PCs. Even
| disregarding the open source stuff, Android was very much
| an open system just for that reason.
| BoorishBears wrote:
| Apple is indeed the driving force that improved "targeted
| advertising, media consumption and unnecessary services
| subscription" compared to the old "Open the Web Browser
| and Owe 10 dollars" days by leveraging their iTunes
| userbase.
|
| Android would not even have launched without the iPhone
| breaking down those doors, you can hear it first hand
| from the Handspring/PalmOS/WebOS folks:
| https://youtu.be/b9_Vh9h3Ohw?t=1609
| acdha wrote:
| Going back to the original comment, iOS improved the
| situation from the carrier having veto power over the
| entire experience to just the phone vendor and the App
| Store is more open than some of the earlier ones were
| (standard terms). It also doesn't have the ad / activity
| data issues.
|
| Android can be more open but let's not pretend that a lot
| of devices have locked bootloaders, too, and has never
| lived up to that "PC" model due to things like
| proprietary drivers and apps refusing to run on unlocked
| devices. The future is very much unsettled here and we
| need something like legislation to reverse that trend.
| sangnoir wrote:
| > Android can be more open but let's not pretend that a
| lot of devices have locked bootloaders
|
| Not all Android handsets have unlockable bootloaders -
| but all handsets with unlockable bootloaders run Android.
| RobotToaster wrote:
| I don't remember having these problems on windows mobile 5.
| akira2501 wrote:
| It was a nascent market, and the first versions of Android
| and iOS were not significantly better than what was already
| being offered. Is the suggestion that we wouldn't have put
| any effort into developing the ecosystem if Google and Apple
| didn't decide to involve themselves in it?
| kolinko wrote:
| What? No, no, no. iOS and Android were night and day
| compared to Symbian and the other operating systems of that
| era. Aside from the very basic games and super-simple apps,
| it was virtually impossible to write anything significant
| for non-Apple/Android devices.
|
| Because of that, even before the official launch of an iOS
| SDK, there were more apps for iPhone (because people hacked
| it), than there ever were for Nokia.
|
| For WindowsCE, sure there were apps, but phones didn't run
| Windows really then. Only PDAs.
| naikrovek wrote:
| no joke. what a hellhole that was.
| Huh1337 wrote:
| I kinda liked J2ME...
| sangnoir wrote:
| You're the first person I've ever heard saying this.
| People used to complain a lot about Android
| fragmentation, but J2ME was easily 50x worse. Maybe 100x.
| MisterTea wrote:
| You mean it how it barley existed and all we did was talk and
| text?
|
| Yes. And it was marvelous.
| int_19h wrote:
| Before Android and iOS, the dominant smartphone/PDA platforms
| were Windows Mobile and Symbian. And whatever their usability
| issues were, I don't recall there being a problem with
| downloading (or even buying boxed) third-party software
| directly from the authors and installing it directly.
| derefr wrote:
| Before Android and iOS, no third-party developer cared
| about smartphones/PDAs, because they were a tiny sliver of
| the market and so you couldn't make money targeting them.
| Bigcorps like Microsoft/Facebook/Twitter might make _free_
| apps for these, just to cover them (since their own
| employees used them); but no ISV cared. If you were an ISV
| developing paid "apps" for "mobile" at all, you were
| developing J2ME apps for feature-phones.
| int_19h wrote:
| That's plainly not true. Sure, there weren't "millions of
| apps" in the store, but like I mentioned above, there was
| actual _boxed software_ sold for those platforms.
| derefr wrote:
| My point is that no ISV ever bootstrapped or got VC-
| funded in the 1995-2007 period by making a bet on selling
| "apps" for the PDA software market; the revenue would be
| too low to keep the company going, and the TAM would be
| too low for even longer-term-minded VCs to be interested.
|
| What probably _did_ happen, a bit, was that ISVs that
| made software for _other_ markets, may have _ported_
| their software to PDAs, and sold that. (E.g. "WinZip for
| Windows CE", things like that.) But that doesn't mean
| that these companies were surviving off of this. These
| were effectively "halo products" (products that don't
| sell many units, which are made instead to increase the
| brand perception of key influencers who happen to have
| such niche interests, and thus influence their
| [influential] opinion of the rest of the product range
| through the halo effect.)
| kolinko wrote:
| As a developer from that era - developing for Symbian was
| absurdly difficult and awkward.
|
| Around 2007 we tried building an app that scanned barcodes
| in a store to show you comparison from online stores.
| Symbian's APIs for cameras were so broken, that we couldn't
| get a decent enough resolution of photos. Java had
| permission/ux issues that made the app unfeasible. It was
| literally impossible to build an app like this back then,
| even though phones had good enough cameras already.
|
| Not to mention the fact that you needed a whole studio to
| build and test even a simple app like this - so many
| variants of OSes, and phones, and every single one had it's
| own quirks.
|
| And to add an insult to the injury - we had to pirate the
| SDK, because the official links to SDKs didn't work for a
| few days, and nobody seemed to notice.
|
| So yeah, in theory the users could download apps to the
| devices. But in practice it was easier for devs to hack
| into iPhone 1.0 and build apps there - even before the
| official app store launch, than it was ever to build
| something for Symbian and the others.
| Aloha wrote:
| Open Source cell phones is functionally a very very niche
| market.
|
| They end up costing more than the phone with the big binary
| blobs from the other android manufacturers, and often have
| older hardware than the hardware makers are willing to give
| away specs for.
|
| For what, I'd ask? The users don't care. 98% of Android and iOS
| users don't even know what open source is, and at least half of
| those who do know, don't really care that their phone isn't
| open source.
|
| The people who buy most of the phones by volume and dollars,
| just want a phone that works well, and lasts 2-5 years.
|
| This was true in the pre-Android iOS version too, I cant
| remember a Sidekick, PalmOS or Windows Mobile caring much about
| it either. Most users don't care much about how the sausage is
| made, provided the sausage is tasty, convenient and cheap.
|
| I donn't think they're afraid of their ecosystem being
| threatened by Open Source, its not even in their field of
| vision.
| AlexandrB wrote:
| With the exception of Signal, I never give apps access to my
| contacts. If you think that's paranoid, remember how apps like
| LinkedIn used this kind of information in the past[1]. Thankfully
| on iOS apps almost always work without contact access (is this
| mandated by App Store rules?).
|
| It's not clear from the article if the app just _asks_ for access
| to contacts or _requires_ it, but if you can 't make your Voip
| app work without accessing my contact list, I don't want to use
| it.
|
| [1] https://www.theverge.com/2013/9/21/4756212/linkedin-
| accused-...
| bryceacc wrote:
| there are multiple apps i have encountered that would not let
| you type in a phone number to start a chat. you HAVE to give
| contact access and have whatever number you wanted to chat with
| saved as a contact
| binkHN wrote:
| > you HAVE to give contact access...
|
| Some apps require this, but the Android API allows apps to
| access very specific Contact information without having full
| access to all Contact data.
| thebeardisred wrote:
| While I don't doubt that you never give apps access to your
| contacts, how many apps do you use as _dialers_?
| londons_explore wrote:
| iOS doesn't even let you change the dialer.
| scarface74 wrote:
| Third party dialing apps integrate with contacts, the
| dialer, your call history etc.
| avisser wrote:
| I have Google voice on my iPhone. Google voice calls show
| up in my "Recents" in the Phone app. When I click them, the
| call is started in Google Voice.
|
| That feels like changing the dialer, even if it's
| technically not.
| cmsj wrote:
| Absolutely the same here. WhatsApp is a nightmare to use
| without contacts, but I don't care, they are not having my
| contacts.
| Nextgrid wrote:
| Facebook wouldn't have paid billions for just a messaging
| app. What they really paid for is people's social graphs.
| thatguy0900 wrote:
| Seems like a lost fight to me, if a few friends have these apps
| your social web is already known to a great extent anyway
| 0xCMP wrote:
| It is, but it's worth being a pain in this respect because it
| makes it obvious we need a way to limit which contacts an app
| can see similar to how you can limit photos for an app.
| donmcronald wrote:
| Yep. I was just looking at a voicemail / spam blocking one
| last night and their privacy policy said they use / share and
| contacts you upload (aka that _they_ upload). The average
| person has no idea that's happening.
| donmcronald wrote:
| > We even sue governments for protecting the privacy of our
| users.
|
| Lost in translation?
| lhobas wrote:
| No: Voys is a Dutch company with a South African counterpart.
| Their Dutch entity sued the Dutch government for not providing
| enough clarity on how mandatory call logs get processed on the
| government side.
| betwixthewires wrote:
| So put it in f-droid.
| mixedCase wrote:
| And nobody will use it because third party stores are
| discouraged by the operating system's UX.
| betwixthewires wrote:
| Lots of people use f-droid. It's as easy as installing
| f-droid from browser and then checking a box in settings.
| mixedCase wrote:
| I am aware. I'm one of them. Unfortunately us "lots of
| people" are still probably <0.1% of Android users.
| betwixthewires wrote:
| But that's not "discouraged by the system UX" and what
| better way to get people to use f-droid than offering
| incentives to use it? Like your favorite app having
| better features when installed from there?
| mixedCase wrote:
| Sorry, but if you do not believe getting security
| warnings, having to go into the settings and mangle with
| configuration, just to be able to install a store
| downloaded from a website, sometimes go through
| additional configuration depending on your phone's
| modifications (looking at you Xiaomi) to then install the
| actual program you wanted is not "discouraged by the
| system UX", despite the real world experiences of
| companies who have tried even simpler things and failed,
| I'm not sure we can agree on what's viable or not.
| Traubenfuchs wrote:
| > Analytics cookies are installed on this website to enhance your
| browsing experience. Such cookies are only used to optimise this
| website's performance and enhance user experience. It is not
| possible to disable analytics cookies on this website.
|
| Now that's just a lie and you know it. Is this legal?
| Marsymars wrote:
| "It is not possible" isn't used by companies to mean "it isn't
| physically possible", it's used to mean "it isn't supported by
| our processes".
|
| (I've been in a frustrating back-and-forth over the past couple
| days with a company who's quoting me an outrageous shipping
| fee, and keeps telling me it's "impossible" to ship with a
| different delivery service.)
| earleybird wrote:
| Can't vs won't.
| MaxikCZ wrote:
| IIRC: At least in Europe, they needn't ask for essential
| cookies. They need to ask for cookies used for tracking,
| profiling, fingerprinting and consent to share collected info
| with third parties.
|
| The rules also state that the path to reject those cookies must
| be as easy as it is to accept them, so if they have "accept
| all" button, they are required to also provide "reject all"
| button, that has similar visibility and accessibility to the
| "accept" button.
|
| IIRC At least in EU, what they do is illegal and dark pattern,
| and hence personally I have no reason to believe their side of
| story on any topic.
| dwaite wrote:
| > The rules also state that the path to reject those cookies
| must be as easy as it is to accept them, so if they have
| "accept all" button, they are required to also provide
| "reject all" button, that has similar visibility and
| accessibility to the "accept" button.
|
| The rules also say that you have to be able to _withdraw_
| your consent as easily as you provided it, which IMHO 99% of
| cookie banners fail to provide for.
| Traubenfuchs wrote:
| That's what I thought. I just started a prolonged burnout
| vacation. How do I hold them accountable / sue them? I will
| look it up.
| Nextgrid wrote:
| You can't _sue_ them. That 's the reason so many non-
| compliant consent flows are out there, and entire
| businesses have been built on providing them as a service.
|
| The best you can do is to complain to your country's data
| protection agency (in the UK this would be the ICO, in
| France the CNIL, etc). The problem is that they aren't
| enforcing the regulation enough to deter non-compliance.
| It's cheaper (in fact, free most of the time, the worst you
| will get is be asked to get into compliance despite
| breaching the regulation for years) to breach it for as
| long as you can than to respect it.
| jeroenhd wrote:
| You report them to your local DPA. The DPA will look into
| the complaint, ask the company to fix the problem and/or
| start an investigation, and maybe eventually, hand out a
| fine.
|
| How long this takes depends on the problem and the capacity
| for the DPA. If Google or Facebook are involved in a new
| data sharing scheme, their cases will get priority over a
| website not setting cookies right.
| rasz wrote:
| I was with you all the way to
|
| >We are now decrypting network traffic to show that we are not
| doing anything with the contacts,
|
| what network traffic? You said its a local phone dialer ...
| kyelewis wrote:
| It's a VoIP app, network traffic is likely.
| savy91 wrote:
| We develop a banking app for families (parents and kids). 2 weeks
| ago we had to remove the possibility to pick phone contacts to
| invite other family members because Google claimed we were
| uploading contacts to our servers (which we did not).
|
| We appealed and it did not work.
|
| We then complied with their request and added to the privacy
| policy they we have access to the contacts and we might process
| them, and yet Google still rejected our app.
|
| In the end we just decided to completely remove every code from
| the app that would allow us to read the contacts on the phone.
|
| This has now made our app UX worse for the 60% of users who used
| this feature.
|
| Also, mind that we of course offered the option to never grant
| this permission so nobody was ever forced to give access to their
| address book.
| refulgentis wrote:
| How did you send invites?
| davidhyde wrote:
| "In the end we just decided to completely remove every code
| from the app that would allow us to read the contacts on the
| phone."
|
| Good, kudos to Google for forcing you to do this. Remember that
| your users don't have the option to do so. The only option they
| have is to not use your app which sometimes is not an option at
| all. And updating a privacy policy is an equally one sided
| affair.
|
| A win win for everyone is if Google allowed the user to turn
| this feature on manually in settings post app install but they
| don't do that.
| veeti wrote:
| The parent comment literally says that their users always had
| the choice, but don't let me interrupt your knee jerk
| reaction.
|
| > A win win for everyone is if Google allowed the user to
| turn this feature on manually in settings post app install
| but they don't do that.
|
| That is exactly how the Android permission model already
| works. But now Google/Play Store is enforcing additional
| restrictions on developers that use these permissions.
| davidhyde wrote:
| Oh, I wasn't aware of this. Call it an uninformed reaction,
| oops. Thanks for pointing out my mistake! Maybe this post
| will be helpful for iPhone users who think that android
| users have no control until it's already too late (I
| thought that, by default, contacts could already be
| uploaded before permissions could be revoked by the user)
| striking wrote:
| Users can decline the permission. Additionally it sounds like
| this was an optional part of the flow ("possibility")
| rawling wrote:
| Did you ask permission to access all the user's contacts, or
| open a contact picker to let them pick a single contact?
| secretsatan wrote:
| I kinda sorta see google's side. There are just too many shady
| operators out there who will swear blind they're completely
| honest, and maybe they are, but they also employed a third party
| to write code or maybe just imported a 3rd party lib (i am in no
| way saying this is the case)
|
| As to, why don't they look at the code? bugger that being
| standard practise, i'm not handing over my code to google or
| apple.
|
| Even if they did, how to check final the uploaded binary?
|
| I'm not doubting the article, but the mobile app world is flooded
| with shady operators at all levels, and i don't really buy the
| real paranoid arguments here
| asdff wrote:
| At the same time, why not just release at least one phone that
| is developer friendly? People can handle it. All these issues
| are present on computers that are able to run unsigned code,
| have sensitive personal info stored on them, etc. Yet the sky
| is not falling with all this going on with everyone's computer
| on earth, like how people fear the sky will fall if we opened
| up the mobile phone.
| nemothekid wrote:
| > _Yet the sky is not falling with all this going on with
| everyone 's computer on earth, like how people fear the sky
| will fall if we opened up the mobile phone._
|
| This is because everything was moved to the web and users
| were beaten over the head with a hammer to never install
| anything on their computers. The sky _was_ falling and
| subsequently the desktop software platform hardly exists
| today.
| TillE wrote:
| I expect Microsoft's built-in antivirus helped a lot too,
| but yeah, the Windows XP era (c. 2001-2010 probably) was an
| absolute disaster of malware.
| jtvjan wrote:
| It's easy to install unsigned apps on Android, but not being
| on the Play Store severely limits your reach, since many
| people only check there for apps instead of searching on the
| open web.
| fsflover wrote:
| >why not just release at least one phone that is developer
| friendly?
|
| Google and Apple want to control their users, they don't want
| to give you an open phone. Instead have a look at Librem 5
| and Pinephone, which run GNU/Linux.
| secretsatan wrote:
| In a way, but not for your reasons, they want to create
| mass market devices that if you give one to your grandma,
| little nephew can twist their arm for the root password to
| install this totally harmless fun app
|
| Apple realised that far more than google imho
| secretsatan wrote:
| They keep making them but they keep failing, because people
| want phones that work without needing a computer science
| degree to understand what is safe and what isn't.
|
| And myself being an apple guy with a dev account, i can
| install pretty much what i want
| ipaddr wrote:
| The initial barrier of getting grandma on an iphone is over
| and the need to dumb down devices to the lowest iq to gain
| marketshare should be over. It is time to raise the collect
| iq and at least offer a way to drop the training wheels
| jonas21 wrote:
| On most (if not all) Android phones, you can tap the version
| 8 times to put it into developer mode and then install
| whatever you want.
| secretsatan wrote:
| Depends what you mean by "sky falling on heads" They're
| definitely aren't concerted efforts in companies to not just
| open any email attachments
|
| No data breaches occur to insecure passwords
|
| Phishing, let alone spear phishing isn't a thing
|
| No popular app has ever found to be doing naughty things
|
| We'll not to the oss crowd anyway, if it does happen, it's
| coz they aren't using open source and checking every line of
| code
| getcrunk wrote:
| I don't know how it is in all cases, but at least when using
| java back in the day, the source of a binary was trivial to
| look at?
|
| And now many apps are written in js
| heavyset_go wrote:
| SafetyNet can obfuscate compiled code so that it's a pain to
| decompile and reverse engineer.
| throwaway27727 wrote:
| Proguard
| tsimionescu wrote:
| Not to mention, given their cookie policy, they claim that they
| are "very privacy conscious" is dubious at best (no button to
| directly reject all non-necessary cookies, navigation to a
| different page to configure cookie preferences, claiming that
| analytics cookies are required).
|
| I'm going to go ahead and say that probably they are
| misrepresenting what is happening.
| yieldcrv wrote:
| I noticed that too
| TheCapeGreek wrote:
| 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 of cookie
| consent depending on where you're accessing from. I only
| started seeing the ability to reject cookies entirely when I
| travelled to EU recently - before it was always hidden in
| dark pattern UX.
| maxboone wrote:
| It's not, it's a Dutch company
| moffkalast wrote:
| The Dutch colonized South Africa again eh? Old habits die
| hard.
| _djo_ wrote:
| No it's not, why would you claim it was? The domain TLD
| is South African (.co.za), the phone number listed is in
| Cape Town, and it's a South African registered company.
|
| > Voys Telecom SA (Pty) Ltd A company with limited
| liability duly incorporated in terms of the Companies Act
| of South Africa, 71 of 2008, with registration number:
| 2013/114285/07, hereinafter referred to as "the Service
| Provider";
| prvit wrote:
| https://www.voys.nl/ exists
| _djo_ wrote:
| Ah, got it. Yup, the Dutch office is the original one,
| there are a bunch of others around the world.
|
| As far as I can tell though each different country office
| operates largely independently, almost as a franchise. So
| it might still be that the South African branch, with a
| registered local entity and no EU-based customers is more
| focused on POPI than the GDPR.
| happymellon wrote:
| GDPR is also nothing about cookies. It is about collecting
| tracking and marketing data about someone without their
| permission.
|
| If you do any tracking and you don't use cookies, you still
| need permission and if you use cookies but you aren't using
| them for data mining then you do not need to ask for
| permission.
| Nextgrid wrote:
| > 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.
|
| The GDPR is exactly the same. Even the ePrivacy Directive
| (the so-called "cookie law") actually covers more than just
| cookies - any method of storage in a user's terminal
| (whether browser local storage, or an app's own database)
| is also in scope.
| happymellon wrote:
| Indeed, and you can also use cookies without requesting
| permission.
| colejohnson66 wrote:
| For example, a login cookie is "essential" and does not
| require consent
| veeti wrote:
| This line of reasoning can be used to reject and remove access
| to literally any app or API. Why offer a contacts API if you're
| not allowed to use it? Who is trustworthy enough to have this
| privilege?
|
| They should just remove all third party API's to access any
| user data. Then we can be certain of privacy, with only non-
| shady actors like Google, Samsung, Facebook, etc. accessing
| saved contacts.
| bakugo wrote:
| So why not just remove the Contacts API entirely then? If it
| exists, "shady operators" can misuse it. Oh and, camera apps
| made by "shady operators" could be sending your pictures to
| questionable places so why not remove the Camera API as well?
| And we can't forget that "shady operators" could be snooping
| through your files so let's remove the filesystem API too.
|
| Actually now that I think about it, any app could be malware,
| so let's just deal with the root of the problems and remove
| support for installing third party apps entirely. Everyone
| should just use apps made by google and nothing else, that way
| you know there aren't any spooky shady operators hiding under
| your bed.
| sgc wrote:
| They won't let you call anything but their crappy camera app
| by intent already, for supposed privacy reasons. As you
| intimate, what is the point of allowing mobile apps, if they
| can't access any of the features of the device? Because that
| is where they are heading, fast. A few crappy google apps
| that require 24/7 spying to work, and then they "protect you"
| from everyone else. Sounds like an old school mafia street
| racket.
| pydry wrote:
| They could just make the contacts API use an inbuilt contact
| picker than just supplies to the app the contact the user
| selects each time they make a call.
|
| I assume they want google apps to have access to the whole
| phonebook without looking too suss though.
| pjmlp wrote:
| They already removed filesystem API for quite some time now,
| you're only allowed to read inside the application directory,
| anywhere else on the device requires SAF.
|
| https://developer.android.com/about/versions/11/privacy/stor.
| ..
| forgetbook wrote:
| Slippery slope--There's a reasonable middle ground between
| "disallow all api access" and "allow all api access"
| mplewis wrote:
| Sure, but the entire problem is that Google does not seem
| to be able to manage the middle ground and proper use of
| it.
| smeagull wrote:
| You're right, Google have long been incompetent at managing
| user generated anything. They should probably stop building
| things that depend on it, because they're so bad at it.
| shadowgovt wrote:
| Interesting (and disquieting). I can see this from Google's
| standpoint also... I don't expect them to shoulder the cost of
| interpreting a binary blob by decompiling it, so they're left
| with the problem that the trust calculus is that they're
| observing a user doing something with very sensitive user
| information in a binary blob they can't introspect.
|
| Hypothetically, one possible workaround (that definitely wouldn't
| work for all companies and requires more trust of Google than
| many will be comfortable with) would be to offer a feature where
| the package uploaded to Google for hosting on the Play Store
| includes source code and _they_ compile it to native... But then
| you have the problem that a company will have to exfiltrate
| source code to a third party (even though the third party is the
| one with total control over their app 's existence in the largest
| Android store).
| mvletter wrote:
| The power they have vs the responsibility they take is completely
| out of balance.
| encryptluks2 wrote:
| LOL... I can see Apple developers saying something like this
| while theu write about it on their even more limited and
| lockdowned devices.
| user3939382 wrote:
| You can agree that company X does Y thing wrong without
| deciding that you will make unlimited practical sacrifices in
| your life to support that position.
|
| If I cut my relationship with every institution I have an
| ethical problem with, I'd be living in the middle of the
| woods in a hut.
| SpaceL10n wrote:
| That can be good thing, imo. Young people have little power to
| change the world around them, yet they take responsibility for
| "making the world a better place". I find it inspiring when
| companies do this too.
| yuvalr1 wrote:
| Alas Google does the exact opposite - they have a lot of
| power (they essentially verdict an app to life or death,
| which sometimes means the death of the business), but take
| very little responsibility for their actions towards app
| developers.
___________________________________________________________________
(page generated 2022-10-20 23:00 UTC)