My head hurts.
it won't really affect the intranet scenario - in which, in my case, no computer would be assigned to a particular person. The discreet part of it would need to be done with login passwords.
So you will have to store the internet-based data on the server, accessed via the login password.
And if you are going to have to build that infrastructure, *ANYWAY*, why would you want to do it any differently for inTRAnet users????
I will grant that you *COULD* do it differently, but why build two completely different systems for the same purpose?
Your question about MySQL I don't understand at all. Are you asking if you could (a) install MySQL onto each and ever inTRAnet user's machine and then (b) from the browser, store data into the MySQL DB that is local to the user's machine????
The answer to (a) is "Of course." Just are you sure you really want to be responsible for maintaining all those databases. I *guarantee* that some users will find out that they have MySQL installed on their machines and start using the DB for their own purposes. You could make it really difficult for them to do this, but it just makes for an incredible systems administration nightmare.
But I will ask again: WHY? It certainly doesn't help the problem of one person logging in from multiple locations and/or machines one tiny iota.
Can you possibly explain why you find the idea of storing data on the local machines so attractive? Perhaps the correct solution, if you are adamant about this, is to *NOT* use a browser-based answer, at all. Simply create a stand-alone executable, with an embededded database engine, and distribute the ".exe" package to all users.