Internal updater #3141
Internal updater #3141
Conversation
smclt30p
requested review from
TobiGr and
mauriciocolli
and removed request for
TobiGr
|
It updated itself to 0.18.5 just fine this morning. |
Nice to hear! To improve update handling, we decided to set up our own F-Droid repository. Can you please take a look at https://gitlab.com/fdroid/update-channels and see if it is compatible with our repo? If it is, it might be a good alternative to the current approach and an work which should be compatible with further changes when completing #1981. |
|
@TobiGr The most efficient and fastest way of delivering updates to users is this new updater + GitHub Pages
The user is notified via the notification, the updater downloads the latest version and installs it. Instant update delivery and installing + you don't need to rent out infrastructure. I did my own thing of "abusing" the infrasturcture of GitHub Pages. If set up in a clever way, it can serve a lot of files without any complaints or outages, for free. If you think about it, fancy programs like APT are just flat file servers (no cgi) that serve flat files. |
|
I like this change. |
|
That can be implemented. @TobiGr is there a need for that? Will the API server stay the same? |
|
I don't think we need to ship a custom-built updater. F-Droid provide everything we need to safely handle updates. People can easily add our repository to their client and download and install updates very comfortably this. There's even a system extension which renders this annoying install dialog obsolete. We'll also be able to provide a seamless experience, when F-Droid ships our own binaries instead of building them theirselves. If in-app updating is really required, it's best to use F-Droid update channels. It's also a much more privacy aware solution.
|
|
If you wanna go all-out tin-foil-hat feel free to disable update checks in the system settings, and don't use the internal updater.
Simple.
Get Outlook for Android<https://aka.ms/ghei36>
…________________________________
From: TheAssassin <notifications@github.com>
Sent: Sunday, March 1, 2020 8:45:36 PM
To: TeamNewPipe/NewPipe <NewPipe@noreply.github.com>
Cc: Ognjen Galić <smclt30p@gmail.com>; Author <author@noreply.github.com>
Subject: Re: [TeamNewPipe/NewPipe] Internal updater (#3141)
I don't think we need to ship a custom-built updater. F-Droid provide everything we need to safely handle updates. People can easily add our repository to their client and download and install updates very comfortably this. There's even a system extension which renders this annoying install dialog obsolete. We'll also be able to provide a seamless experience, when F-Droid ships our own binaries instead of building them theirselves.
If in-app updating is really required, it's best to use F-Droid update channels. It's also a much more privacy aware solution.
As far as I know, currently the GitHub API is queried to display the update notifications. @TobiGr<https://github.com/TobiGr> does any privacy document mention this? Do you fetch people's consent before running update checks?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#3141?email_source=notifications&email_token=ADKRL645EVII7VP2GXS6JXTRFK3OBA5CNFSM4K3RCKM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNI2XA#issuecomment-593136988>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADKRL66HBAOWSJGSPINGP7TRFK3OBANCNFSM4K3RCKMQ>.
|
|
There is no need to get rude. We take privacy serious as a project. It's our very selling point, after all. And we have to ensure we comply with law in many jurisdictions. Why are you trying to belittle privacy awareness? Anyway, we (the maintainers) have come to the conclusion that we do not want to ship an "internal updater". That unfortunately means we will not merge your PR. An advice from a free software developer and long time maintainer: Please contact a project beforehand next time. This way, details can be discussed before anyone invests time to write code. All stakeholders can bring in their points and a final decision can be made. There is no need to become rude if there's criticism to the concept. In most cases, problems can be sorted out. As written above, an updater based on F-Droid's update channels concept may be acceptable. If you are interested in implementing one, please don't hesitate to open an issue and discuss the idea. |
|
Your "privacy" is already compromised with the code that already *exists* inside the project.
I used code that already *exists* and is executed *each* time NewPipe is executed.
If downloading the *same* file via a browser redirect is easier, be my guest.
All this PR does is move that *existing* logic into NewPipe.
Get Outlook for Android<https://aka.ms/ghei36>
…________________________________
From: TheAssassin <notifications@github.com>
Sent: Sunday, March 1, 2020 10:58:25 PM
To: TeamNewPipe/NewPipe <NewPipe@noreply.github.com>
Cc: Ognjen Galić <smclt30p@gmail.com>; Author <author@noreply.github.com>
Subject: Re: [TeamNewPipe/NewPipe] Internal updater (#3141)
Closed #3141<#3141>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#3141?email_source=notifications&email_token=ADKRL63HDCRPCZ55THRUUH3RFLLADA5CNFSM4K3RCKM2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOW7XUXYI#event-3085913057>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADKRL65SFDFUMYRLA5MRZ6TRFLLADANCNFSM4K3RCKMQ>.
|
|
Would you mind to elaborate where privacy is compromised? |
|
Would you? You mentioned privacy problems first.
I used a class that I did not write to perform update checks.
Check out `CheckForNewAppVersionTask'
All this PR does is add an apk downlaoder, that downloads the same apk NewPipe already forces you to download via the notification.
Did you read the diffs at all?
Get Outlook for Android<https://aka.ms/ghei36>
…________________________________
From: TheAssassin <notifications@github.com>
Sent: Sunday, March 1, 2020 11:07:17 PM
To: TeamNewPipe/NewPipe <NewPipe@noreply.github.com>
Cc: Ognjen Galić <smclt30p@gmail.com>; Author <author@noreply.github.com>
Subject: Re: [TeamNewPipe/NewPipe] Internal updater (#3141)
Would you mind to elaborate where privacy is compromised?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#3141?email_source=notifications&email_token=ADKRL6YXRKIA3FWQVIN5USTRFLMBLA5CNFSM4K3RCKM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNMNXA#issuecomment-593151708>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADKRL66JBXBKLPPYBQG3AGTRFLMBLANCNFSM4K3RCKMQ>.
|
|
Yes, I did. But still, you could be more specific what's problematic if you claim the existing code is. I do have doubts you have read the code of the API you're using to fetch the URL of the APK. Here's the summary of why your code adds problems: The update check connects to our own infrastructure where a (free software) web API provides the data you were using. This service is provided by us, along with a privacy policy that complies to the EU GDPR. What you implemented connects to GitHub, a service outside our control with questionable privacy. It does not run on free software. They do excessive logging, which, in their jurisdiction, may be legal. Our service doesn't. We store logs in anonymized form and don't retain any data for any longer than we have to (if we even collect data). What is missing is information on what happens when you update through the app. You make a connection to GitHub and download some files from there. The user cannot trivially see what's going on. They are made aware of our own privacy policy, but as soon as third parties are involved that is not sufficient any more. The privacy policy does not cover any GitHub updating. And even that might not be enough. To be on the safe side, the actual connection to GitHub requires you to ask for users' consent. You need to ensure the people have been informed that their device will make a connection to GitHub, and you will have to tell about their privacy policy (a link is sufficient there). I've raised the same concerns about the connections to the other services, as you may have read. What you might've missed is that we continued the discussion on IRC. And it's off-topic in here anyway to discuss whether we need to check for users' consent when connecting to Google's video infrastructure for instance. You are not the person responsible for the data collection, others are. It's a normal process for them to review the legality of your contribution. Same goes for regular revision of existing code, law is not a stable entity but is changed all the time. Compliance is very important, not only because you might get sued, but because adhering to laws protects both you and the users. |
|
So, notifying a user and redirecting them to a Github service is ok, but using an internal downloader that downlaods that same file is a problem? There is a greater chance for you folks to get sued by Google for providing services that enable illegal downloading and streaming from their infrastructure. Read "abuse" of infrastructure. What NewPipe does is strip the content of their ads and serve it on a silver plate for streaming and downloading. Privacy policy? Is that even relevant? The application is banned from the Play Store. The only people that can sue for damages is Google, not the EU. What a waste of time. |
|
You don't seem to have an understanding of legal topics. You're making a few very false and worrying claims. Let me help you a bit.
Yes. If we just show them a URL they can click on or a button or so, that's perfectly fine. They leave our area of responsibility. A website may not even set cookies before requesting consent in the vast majority of all cases. Many websites just violate the laws, though.
It is not illegal to ship a tool automating the download process. It's up to the user whether to use the app or not. The license clearly says we reject any warranties or responsibilities. That applies to most free software.
It is very relevant. If data is processed in an automated way (no matter if digital or analog), it is subject of data protection and privacy laws. I hardly know any software that doesn't process data, do you? Of course, the laws usually apply only if personal data is being processed, but there's always some rules on regular data processing as well.
The application is not banned from the Play Store. It has never been added there. That's a false claim. Also, Google's play store rule stuff are not laws. They're basically contracts which you can break. That's not the same as a violation of a law.
What gives you the impression the EU has anything to do with this? Parties in the context of the GDPR are people who offer services and their users. I've stated earlier where we act as a service provider. There we are responsible.
I've explained to you that your contribution strategy was not ideal. Opening PRs with features that haven't been explicitly approved is always a risky business. The main reason to reject yours is not related to privacy concerns, those could've been sorted out, but the preference for F-Droid and their update channels. |
|
I have to mention that I am not a lawyer, if you have any questions you're best off seeking a lawyer's advice. I'm not providing legal advice. |
The way you are speaking about privacy really doesn't align with anyone here, and you are further minimizing your chances of getting anything productive done by being rude. |
|
This is actually more privacy aware than a browser redirect. The browser would send all the cookies along with the request. Also, if the server gets compromised and starts serving malicious apk links, an internal updater can suppress that by doing some signature check whereas the browser redirect won't. The fdroid update channels is very old code(unusable without major changes). It is not even being used by any app that I know of. |
|
i am not a lawyer but can i suggest a middle ground here. If the requirement is that the user needs to be given a new page with the notice that a file in this case the apk is going to be downloaded from an external service (here github) and that their privacy policy is in the link below. if the user agrees, the apk is downloaded directly and this pr will be used. if not, they are sent to the existing method of visiting the website and then downloading from there? are cookies involved in case of hotlinking because you are not requesting a webpage but just a file.?
|
|
Chiming in here... I would personally like an internal updater. It makes things easier for all of us. If consent is needed, why don't we ask upon installing if the automatic updater should be enabled? The person clicks on accept, accepting the terms mentioned above and it's good to go. If GitHub is not okay, maybe download the file from F-Droid, but with that same direct method. Imo, this PR should get accepted, with some little modifications (terms and another page url maybe) |
This adds an internal updater, that is used instead of the external download action. It also adds a "check for updates" action to the update settings
The updater:
CheckForNewAppVersionTaskCheckForNewAppVersionTaskto Downloads/newpipe.apkThe edits to existing code are minimal