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.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/40945027.Ov4JLljASd%40strawberry.
For more options, visit https://groups.google.com/d/optout.

Reply via email to