Is this tunneling traffic from devices to Device.farm's servers? That's what it looks like is happening here[1].

This is the message on both the ToS and Privacy Policy pages:

> TO BE DONE...

[1] https://www.cnx-software.com/wp-content/uploads/2020/05/devi...

Yes, there is VPN tunel from the device to device.farm servers. It is openconnect VPN. device.farm server then acts as a reverse proxy. User needs to authenticate in order to access the device's service. We are sorry, there is no ToS and Privacy Policy available yet, it should appear in following days.

Before I'd use something like this, I'd like to see a privacy policy and at least a simplified topology of the networking, where and if encryption is terminated, what information is sent or stored, etc.

Looks cool, though! Are you running a standardized kernel for the images, or are the kernel builds board specific and thus different versions?

I can understand your concern if there is no privacy policy nor documentation and whole thing seems like a black box. To be honest, the post on CNX-SOFTWARE was published a bit faster than we expected so we are catching a running train now :) Anyway, PP, ToS and documentation is the priority now. We would like to be as transparent as possible, most likely the whole solution will be open source in future. To your question about kernels: to simplify it for now, we are just modifying standard Armbian and Raspbian images available on their websites. Complete build process on our side is something we are considering to implement.

> openconnect

Any special reason? The main advantage that I would expect over ex. Wireguard is maybe better (pre-existing) authentication integration but I'd be curious about your reasons.

The reason was easy integration with PostgreSQL over PAM. I will check if the same could be achieved with Wireguard. Technically, already deployed devices can switch to other VPN tunnel, so there is nothing preventing us from the change.

I discovered https://github.com/solo-io/packer-builder-arm-image recently. The doc mention RPi/raspbian a lot but it works well for armbian on other devices for example. I use it to build images for my SBCs with ansible packer provisioner. Pretty cool.

I made a small script a few month ago, for anyone who wants to understand how generate a compact Raspbian image : https://github.com/Blafy/raspbian-build It's a ~50Mb image, compatible for Raspi 1 to 4 !

Nice!

And you are supposed to trust images not to have vulnerabilities?

There is no warranty that these img files do not contain malware or vulnerabilities. Why the Dockerfiles are not public?

Which Dockerfiles do you mean, please? There are only Linux images. Dockerfiles are then prepared by owners of devices.

I really hope some of such images are providing some user-friendly in field WiFi setup just like any smart home devices.

Can't speak for Raspian, but Armbian has https://docs.armbian.com/User-Guide_Armbian-Config/#network

Simple enough?

I think that's not what op meant: If I understand your link correctly, that's a tool to help connect to various networks if you have a shell on the device. If you don't, that won't help. What you need in that case is that the device itself opens up a temporary access point that you can use to configure the device.

99% of time i want to be able to connect device anywhere. For example, give it to customer, friend, family to check out. It is to much hustle to hardcode this to a device while i literally just want to be able to configure this on first run.

The article says you enter the credentials and then the site generates an image that can connect to that WiFi.

So these guys will have IP addresses, wifi network credentials and root passwords for all devices using their services.

The site will provide you with a root password for your embedded device, and you will provide the site with the wifi network and credentials needed to access the network where the device is.

That doesn't sound like good security practice.

So... What is with this trend of making a web service out of something that ought to be a shell script?

Reminds me of yesterday's hn post about making your PDFs look scanned by... Uploading to a web server that runs a ghostscript command.

It's almost as if locally running software is deeply confusing to people and the perception is that you need to have a potentially privacy violating service if you have a friendly ui. Not to mention all the energy wasted running those servers. Is this how bad our society has gotten at writing software?

In 2020, most people's only device is a cellphone.

They can't easily run ghostscript directly, and making a web service is easier than making an app (recompiling ghostscript for all CPU architectures, ...) despite the ongoing hosting costs.

I feel like the right answer to that is to make ghostscript run on a cell phone. I mean... we're already on Darwin or Linux; the userland is weird, but ex. Termux and iSH proves that you absolutely can run a lot of packages all the same. So in my mind, the real question is: Why does the porting and app development experience suck so much? I mean... HyperCard, in 1987, was usable by non-programmers. A/UX had Commando in 1995, which wrapped CLI in a nice GUI. To hear people rant, the height of RAD GUI building was Visual Basic 5 (1997) or VB6 (1998). Have we really lost that much in the ensuing 25 years?

Not just hosting costs. Energy costs. Destruction to our planet.

That is also in addition to sending your documents to who knows who.

You can probably compile ghostscript to javascript via emscripten or similar. I am not sure what this means for its AGPL license.

But maybe this is more a discussion for that other thread.

> You can probably compile ghostscript to javascript via emscripten or similar. I am not sure what this means for its AGPL license.

Shouldn't be any "worse" than running it server-side, since AGPL exists in order to apply to SaaS.

You can change the root password after first boot the same way you would do with Raspbian or Armbian image. We just want to shorten the time the device is running with a default password. You can think of that entered password as it is a temporary one. Wifi configuration is completely optional. You can leave it unconfigured and do it later over serial line. We don't keep any credentials on our servers.