Thanks for your mail!
I think we are getting to the core of our little discussion :-)
On Thursday, 21 December 2017 19:02:23 CET Unman wrote:
> Since templates can be customized by the user it is not true that they
> cannot contain private data.
They can contain private data, because they have harddrive space. So
technically speaking you are not wrong.
Do you have any reason to believe there is any incentive to store your
private data, your account info (password) etc in a template?
> It's a moot point to what extent Templates do
> contain identifying material, even when not customized.
The entire point of Qubes is compartmentalization, which means actively
choosing where you have your login data, your keys and your private
messages.
A security worry that assumes people will copy their darkest secrets in
inappropriate qubes is a bit... odd.
And that is exactly what you say when you argue placing material you want to
keep secret in a template is a moot point.
> It isn't true that Templates CANT contain listening services,
This is true only if you pick your words very specifically.
It is true that template can try to listen to someone out there.
But its pointless because the Qubes system doesn't allow anyone to connect
to your templates. There is no port forwarding to your templates. Just
connecting to sys-net will not make that magically happen.
Bottom line is that no hacker can connect to your services on your template.
And thus you can’t get remote hacked by doing nothing.
> or services
> that make outbound connections without user intervention. Debian
> Templates will start some services on installation, for example, and
> there are other "aids" that may initiate outbound connections without
> the user's knowledge. There are circumstances where this could be
> extremely undesirable.
Interesting to hear, you maintain the Debian RPM for Qubes, right?
Can you explain which services are started automatically and do outbound
connections in that template?
You seem sure, so please share that info.
> If (e.g) you use a web browser in a Template there is every chance that a
> hacker may install bad software without your knowledge.
I highly doubt that. If that were true most Ubuntu boxes would have been
turned into bots.
But more importantly, the advice to only run software to update your
template stands.
The template VM is started for updating your operating system, it is not for
playing a flash game or running Skype. This was always the advice.
> If the Template is compromised then all the AppVMs that use it
> will be compromised.
This thought is not false, but your thoughts of how a template can get
compromised are clearly unfounded.
As you have admitted multiple times; all these technical things that make
basic tasks more difficult are there only to protect the user from
user-mistakes.
To be clear, I can get on board with the idea that users should be
discouraged from *using* templates. User training you called it.
I think the two different schools of thought here are that you work with
rules a lot. Decide that users can't do X or Y or Z, and you solve the
problem.
This works in a company, this works for a certain set of users.
I come from a different background, after 17 years of doing open source I
learned that telling people what NOT to do will always lead to
disappointment. :-)
Finding more user friendly ways of telling people what is a better way to
solve a problem is the direction I'm leaning towards. Lead, not punish.
As a quick example; make templates have a config file that indicate which
software is the ‘updater-GUI’ and make the icon-updater use this info to
only show a limited set of start-menu-items for template VMs.
A second icon associated from a template would be
“create VM based on this...”.
My thinking is that we have to work *with* people, not against them. Provide
more useful options, don't take away ones you think are dangerous.