Old build detect macOS

[kelyvin]

Old build detect macOS

[kelyvin]

Eee yikes. I will try to take a look at this over the weekend and get a build out that resolves this.

[aayushus]

@kelyvin any update on this?

[kelyvin]

@mercplus @Matgen84 Sorry for the delay on this. You can download the latest versions here:
https://github.com/kelyvin/Google-Messages-For-Desktop/releases/tag/v1.3.0

Hope that fixes your issues!

[ronjouch]

Hi @kelyvin . Nativefier maintainer here, coming from nativefier/nativefier#1131 (comment) and nativefier/nativefier#1148 .

1. Thanks for having addressed this 🙂.
2. I stand by this feature; letting people browse the web on a crazy old Electron/Chrome is an undiscutably bad thing (for security foremost, and performance)...
3. ... that being said, at time of adding the feature, I didn't think about "pre-packaged" apps like yours. I had in mind users building their apps on their own, and able to understand the "please upgrade & re-build" message we're throwing at them.

→ So, I think you should override the message to something more targeted, and understandable by your target audience, e.g. something like Google Messages for Desktop is out-of-date. Please download the latest version at https://www.messagesfordesktop.com/ . Maybe you also want to tweak OLD_BUILD_WARNING_THRESHOLD_DAYS to something slightly higher than the current value of 60 days (but not too high please, security is important).

Notes:

• Nativefier at the moment does not offer options to customize the message and threshold, and given we already have waaaaaaaaaaay many flags, I'd like to avoid yet another obscure one. But given the position you're in (of packaging), it seems reasonable to expect you to do a build-time patch / string replace.
• Note that Nativefier offers flag --disable-old-build-warning-yesiknowitisinsecure. For your use case, please do not use it. As documented, this is targeted at corporate users using Nativefier to expose kiosk versions of tightly-controlled apps. This isn't the case here.
• Yes, all this puts extra burden on you, the packager and distributor of a Nativefier app. And again, I think that's reasonable given the security consequences. You're distributing a web browser, it's your job to push updates periodically.

Does this all make sense? Any feedback/disagreement? Thanks.

[kelyvin]

Hi @ronjouch. I really appreciate you coming here and helping to shed light on the situation and for being so thorough with your suggestions. I also want to thank you for all your work on Nativefier to make it extremely simple for me to pre-package these apps for general audience usage. I originally started this pre-packaged project for my personal network to use, then I used it as a marketing experiment, and it kind of blew up from there.

I only half agree with your second point, but I respect your decision, so other than that there are no disagreements here. I am a library maintainer myself and know what it's like to step a day in your shoes, as well as the work you do to make everyone happy. I think the suggestions you made are reasonable.

As for feedback, I just have a question regarding your first bullet point (of wanting to avoid additional flags). Do you foresee a future of supporting configs, i.e. a way for me to just set up some config hooks to alter some of these nuanced options myself (or do you already support this and I'm just really bad at reading docs)?

Thanks!

[ronjouch]

@kelyvin thanks for the kind words 🙂.

I have a question regarding your first bullet point (of wanting to avoid additional flags). Do you foresee a future of supporting configs, i.e. a way for me to just set up some config hooks to alter some of these nuanced options myself (or do you already support this and I'm just really bad at reading docs)?

1. Regarding the topic of auto-updates discussed here: in order to let you apply your packager tweaks without having to patch the JS, I could make OLD_BUILD_WARNING_THRESHOLD_DAYS and OLD_BUILD_WARNING_TEXT overridable via undocumented environment variables. (The intention being to limit expansion of docs & flags, and to not expose the threshold in the docs). 👍 / 👎 / other ideas?
2. Besides the topic of auto-updates: any other examples of things you'd like to adjust, but cannot?
3. Finally, maybe warning on builds older than 60 days was a little bit aggressive. I could agreeish with someone arguing that it's excessive to demand as frequent upgrades from Nativefier apps as you'd expect from a regular browser, given that a typical Nativefier app stays within a known "probably safe" (of course with caveats) site, with less wandering around the wildest parts of the web. I could bump the default to, say, 90 days. With the Chrome release schedule, this is two Chrome versions. Thoughts?

[kelyvin]

@ronjouch Sorry for the late response. Thanks for your reply!

Here are my thoughts on all of your points:

Regarding the topic of auto-updates discussed here: in order to let you apply your packager tweaks without having to patch the JS, I could make OLD_BUILD_WARNING_THRESHOLD_DAYS and OLD_BUILD_WARNING_TEXT overridable via undocumented environment variables. (The intention being to limit expansion of docs & flags, and to not expose the threshold in the docs). 👍 / 👎 / other ideas?

I think that'll work perfectly for me! As long as I have a "hook" and make it easy for me to customize without needing to dive into the code, that should do the trick.

Besides the topic of auto-updates: any other examples of things you'd like to adjust, but cannot?

Personally I can't think of anything right now. One of the reasons why I like Nativefier is that generates a cookie-cutter app with a simple CLI command. Any other additional features are potentially outside the scope of the project and may dive a bit too much into Electron configuration territory (e.g. being able to have a setting within the compiled app to enable/disable tray icons, etc.). Those would definitely be nice to have, but I wouldn't expect support for it.

Finally, maybe warning on builds older than 60 days was a little bit aggressive. I could agreeish with someone arguing that it's excessive to demand as frequent upgrades from Nativefier apps as you'd expect from a regular browser, given that a typical Nativefier app stays within a known "probably safe" (of course with caveats) site, with less wandering around the wildest parts of the web. I could bump the default to, say, 90 days. With the Chrome release schedule, this is two Chrome versions. Thoughts?

90 days (i.e. up to two browser versions) is a reasonable approach. But to be honest, 60 days is fine too. Honestly, 60 vs 90 days doesn't matter because this is more of a personal time-tracking problem. I just need to remind myself to update the apps. For this repo, I can probably set up a CI job or Github action to set up constant releases, which would probably solve 90% of the issues that get reported here.

[ronjouch]

@kelyvin alrighty. In freshly-released Nativefier 43.0.1,

1. I bumped the threshold from 60 to 90 days, I like it better too, to not annoy too much my own users.
2. You can now override the warning text in your builds with environment variable OLD_BUILD_WARNING_TEXT. It will be bundled in nativefier.json and preferred to the default message. See

https://github.com/nativefier/nativefier/blob/f64c05f735a4211cb1685b5cc0676db966aca785/src/build/prepareElectronApp.ts#L72-L77

and

https://github.com/nativefier/nativefier/blob/f64c05f735a4211cb1685b5cc0676db966aca785/app/src/main.ts#L231-L233

[adambraun82]

@kelyvin seeing the old build error msg -- don't happen to have an update for this by chance? This app is awesome and allows better productivity while keeping in touch with my work/personal folks. Thank you for building it!

[RealYHD]

Hi, I'm still having this issue on Windows 11. I'm on version 1.3.0, although perhaps I'm misunderstanding something?

[creampuffyness]

I am also getting this issue on Windows 11, but not on a Windows 10 laptop running the same version.

Edit: I ended up using this link to rebuild it myself. No more errors.

https://medium.com/@jrejaud/desktop-version-of-android-messages-for-web-62892d9640fe

[RealYHD]

I am also getting this issue on Windows 11, but not on a Windows 10 laptop running the same version.

Edit: I ended up using this link to rebuild it myself. No more errors.

https://medium.com/@jrejaud/desktop-version-of-android-messages-for-web-62892d9640fe

Yeah, that's a good idea, I ended up using nativefier myself. Works well.

EDIT:
Oh by the way, (you may already be aware of this and decided against it, it's not unreasonable) there does seem to be a boolean argument in nativefier that disables this error, in case that's something you want.
--disable-old-build-warning-yesiknowitisinsecure
If this repository should become a simple place for people who just want to easily be able download and run Google Messages, maybe this repository should set up some sort of automation where on a new version of chrome release, a simple nativefier script is ran to update the build? Then, the above flag can be used without as much worry (since I believe nativefier doesn't actually check version as much as it just checks how long since it was built).