Author Topic: Synch Settings  (Read 33694 times)

Offline quixin

  • Hero Member
  • *****
  • Posts: 538
Synch Settings
« Reply #15 on: October 10, 2005, 03:29:00 AM »
Quote
Or you could think ahead a little and bring your RDF file with you on a flash drive, or email it to yourself via an account that you specifically know the password for.

Come on - there is no perfect solution for something like this...

What if your PDA dies?

This shouldn't be a problem once you have the ability to import your rdf to the online version.  You can store your rdf on an ftp and have assess to it without having to carry anything around.



Offline ajw

  • Jr. Member
  • **
  • Posts: 81
Synch Settings
« Reply #16 on: October 10, 2005, 04:21:38 AM »
Quote
Or you could think ahead a little and bring your RDF file with you on a flash drive, or email it to yourself via an account that you specifically know the password for.

Come on - there is no perfect solution for something like this...

What if your PDA dies?

(remembering I'm thinking of this as [eventually] the single-storage place for all secret data)

(This reads harsher than I intend it to be - I mean it to be observational, with a hope that I'm right in the expected future directions - I don't mean to be sarcastic)

And this helps how when you're at the airport ticket counter and you want to give them your frequent flyer number?

Or at the ATM and you don't remember your PIN because you don't use the ATM much?  (actually, I *have* forgotten my PIN - but it's in my PDA...   :)

Or you're filling in papers and need your wife and kid's Social Security numbers?

Or you need the number to your Secret Swiss Bank Account?


Sure, PDAs do die, and they do get left behind.  But for every time that's happened to me, there's hundreds of times I've needed Secret Information - and I wouldn't have had access to a web browser, but I've *had* my PDA with me!

If PM is only to generate passwords, you're right.  And if that's all it is, I'm in the wrong place.  If it's (by intended design or evolution - or my gentle prodding and nudging :) going to end up as a good place for all secret information, with syncing between computers and PDA, and the ability to fill in web pages - then I'm in the right place and just need to wait for it all to get there.

From what I've heard so far, it's close to what I want already or will be soon; I'm willing to wait (or help!) with the PDA sync (and other stuff as I can), as long as I know it's coming...

Or, maybe I'm fooling myself and just pissing everyone off - if that's the case, I apologize!

- Al -

Offline ajw

  • Jr. Member
  • **
  • Posts: 81
Synch Settings
« Reply #17 on: October 10, 2005, 05:02:21 AM »
Quote
Quote
By no means do I disparage Eric's work so far - please nobody take it that way! I just (kinda sorta strongly) feel that there's more to it, and PM could be that more.
Maybe, but adding secure 'storage' to PMs list of features will in no way solve Tyr's particular problem either.
Unless syncing (to FTP/online PM) worked now, or he had PM in his PDA (with the correct settings - that probably means syncing too; otherwise it's manually setting the same settings in both places - error prone)

Quote
Quote
He's already said he'll be encrypting the "pre-defined password" field
Haven't heard of this feature... whats that?
Not sure where it is around here - somewhere there was a discussion of keeping existing passwords (not generated by PM) in the "prefix" field.  (actually, that's been in a few places...  :)

Eric brought up that the prefix field is stored in clear, and that he'll (or he could?) change that so it's encrypted.  If I remember correctly, he said something about creating a separate field for this purpose, and encrypting that too.

I *think* it was in the same conversation that he said he could encrypt the Description field, so when it's multi-line (and I'm using it for PINs, Social Security numbers, frequent-flyer numbers, etc) it'll be encrypted.


Quote
Quote
I'll still argue that I don't think multiple replication would be that difficult given the small amounts of data we're dealing with (as opposed to, say, a credit-card database, or source-code files for a large project). But I don't think it's so important that it's needed, either.

It's not the amount of data that is at issue - it is the functionality itself. You can get this kind of functionality with an Enterprise Oracle Database - but at what cost?

PostgreSQL has an Replication Server, but have no idea the extent of its capabilities.

Anyway, we're a ways from this, so there's plenty of time for debate.
Oh, my!  Are you thinking the *servers* would sync amongst themselves?  I supoose that's possible, but I wasn't thinking that - I was thinking I'd sync my *notebook* against server A, then server B, then server C...

I can see the usefullness of server-to-server automagic syncing, but I can also see cases where your server can't *get* to mine (maybe my ISP won't allow external servers access to its PM backup server?)


The reason I brought up data size is that it changes the equation - for example, if we've only got three passwords (account records in PM) then it's trivial to sync amongst however many machines you've got - you get something like this:

server A:  my record 1 is at change number 5.
server B:  mine's at 6, here's the new one.

server A:  my record 2 is at change number 3.
server B:  so's mine.

server A:  my record 3 is at change number 17.
server B:  mine's at 16, send record 3.


Actually, that could be the same conversation between notebook and server; doesn't matter.

Then simply repeat the entire sequence for the next server:

server A:  my record 1 is at change number 6.
server C:  mine's at 5, send record 1.

server A:  my record 2 is at change number 3.
server C:  so's mine.

server A:  my record 3 is at change number 17.
server C:  mine's at 23, here's record 3.


Then server A syncs the same way with servers D, E, F, and G.

Server A now needs to call B up and update record 3 (or can simply remember that *something's* old on B and do a full sync with B).

server A:  my record 1 is at change number 6.
server B:  so's mine.

server A:  my record 2 is at change number 3.
server B:  so's mine.

server A:  my record 3 is at change number 23.
server B:  mine's at 17, send record 3.

If F (for example) also had newer data than A during the initial first pass, then A would re-sync with B, C, D, and E.   (G's already ok 'cause it was sync'd after F's changes)

Now, A, B, C, D, E, F, and G are all in sync.

If (for example) B changed A again during the second pass, then A would re-sync with C..G.

It's best if A syncs with all servers first, and then goes back to re-sync; that way after the first sync, A has all the up-to-date info, so unless there are new changes then it's only two passes.

Expand it to 1,000 records - doesn't matter; same thing works - but only because the data is relatively stable; it's not constantly changing under your feet.  (nobody's going to be syncing their notebook and changing the desktop data and syncing that and then running to the notebook and changing it and syncing that again - over and over again)

It's quite different from a huge active database, where there'll be many transactions at the same or other servers during the time a single sync takes place.  For those, certainly you need Oracle-level horsepower.  For this, not needed at all - first, it's highly unlikely there'll be more than one machine syncing at a time (meaning me syncing my desktop to server A and my notebook to server B at the same time, each with different changes)  so typical case is one-pass, occasional two-pass.  Incredibly rarely (and probably only when intentionally coordinated) more than two passes.

I don't see *any* need for the database manager to handle syncing real-time data with other servers!  (hot backups of the database itself are another story - but that's not accessible to the user-sync, so that's not a problem either)

But, as you say (and I agree) - there's plenty of time before this!

(ain't it fun to argue, though?  :)

(the term I use for this is "arguetect" - we argue back-and-forth until the design is architected...  : )

- Al -

Offline tanstaafl

  • God Member
  • ******
  • Posts: 1363
Synch Settings
« Reply #18 on: October 10, 2005, 11:26:12 AM »
Quote
Quote
Or you could think ahead a little and bring your RDF file with you on a flash drive, or email it to yourself via an account that you specifically know the password for.

Come on - there is no perfect solution for something like this...

What if your PDA dies?
This shouldn't be a problem once you have the ability to import your rdf to the online version. You can store your rdf on an ftp and have assess to it without having to carry anything around.
My point exactly!

Quote
And this helps how when you're at the airport ticket counter and you want to give them your frequent flyer number?
? You did bring your PDA with you, didn't you? :silence:

<snip>

Quote
If PM is only to generate passwords, you're right. And if that's all it is, I'm in the wrong place. If it's (by intended design or evolution - or my gentle prodding and nudging smile.gif going to end up as a good place for all secret information, with syncing between computers and PDA, and the ability to fill in web pages - then I'm in the right place and just need to wait for it all to get there.
Ok, I've given this some thought - and the fact is, I really can't see how it would be all that difficult to add what you are asking for, and it really wouldn't impact the interface or anything much at all.

The simplest way I can think of to do this would be to add the concept of 'Account Type', with the default being 'OnLine' or 'Password' (meaning, a web or ftp based account), and a secondary being 'Info' or something like that. Then, when creating a new Account, if you choose 'Info' for the 'Type', basically all you would have is a big Comments field where you could type anything you want. Do I understand what you are asking for ok?

I can see where this would be useful, but what I would suggest is write up a Feature Request, Post it, and see what happens. The worst that can  happen is Eric will say no.

Quote
Or, maybe I'm fooling myself and just pissing everyone off - if that's the case, I apologize!
Not at all - but you are doing something that I did once - asking for something that no one else seems to want or need - and getting frustrated by everyone's reluctance to jump on board all at once.

Offline tanstaafl

  • God Member
  • ******
  • Posts: 1363
Synch Settings
« Reply #19 on: October 10, 2005, 11:40:20 AM »
Quote
Quote
Quote
He's already said he'll be encrypting the "pre-defined password" field
Haven't heard of this feature... whats that?
Not sure where it is around here - somewhere there was a discussion of keeping existing passwords (not generated by PM) in the "prefix" field. (actually, that's been in a few places...)
Ahhh - yes, I remember now...

Quote
I *think* it was in the same conversation that he said he could encrypt the Description field, so when it's multi-line (and I'm using it for PINs, Social Security numbers, frequent-flyer numbers, etc) it'll be encrypted.
Ok, understand now. Yes, if this FR gets implemented, encryption would be necessary (or the purpose would be defeated). So I guess I'd have to add back in the Encryption choices to the Account Type 'Info' I mentioned in my previous post.

Quote
Oh, my! Are you thinking the *servers* would sync amongst themselves? I supoose that's possible, but I wasn't thinking that - I was thinking I'd sync my *notebook* against server A, then server B, then server C...
Of course... that is how LDAP replication works - it is *strictly* a server-to-server synchronization - all an LDAP Client does is *read* from an LDAP server.

Quote
I can see the usefullness of server-to-server automagic syncing, but I can also see cases where your server can't *get* to mine (maybe my ISP won't allow external servers access to its PM backup server?)
It is just delayed - there is very stable code in LDAP to handle such things.

Everything else you said is not productive - as I said, this kind of code is very stable, and has been for some time. We do *not* have to reinvent the wheel here, so you can either take my word for it, or go read up on it, but I don't have time to debate it (and wouldn't understand the code anyway).

The nuances of how to handle certain kinds of collisions may require some finessing, but that won't be the hard part - the LDAP (or whetever we choose to go with) schema and back-end code will be the hard part.

Offline tanstaafl

  • God Member
  • ******
  • Posts: 1363
Synch Settings
« Reply #20 on: October 10, 2005, 02:15:27 PM »
Quote
Everything else you said is not productive - as I said, this kind of code is very stable, and has been for some time. We do *not* have to reinvent the wheel here, so you can either take my word for it, or go read up on it, but I don't have time to debate it (and wouldn't understand the code anyway).
Sorry, didn't mean for that to sound the way it did...

What I meant was, I don't see a need to debate *how* to do it, since the code is already written to do it and works very well. All Eric has to do is decide which *existing* method to implement, and do it. Hopefully we can help him by discussing the different methods, and give him some ideas.

Offline ajw

  • Jr. Member
  • **
  • Posts: 81
Synch Settings
« Reply #21 on: October 10, 2005, 07:24:30 PM »
Quote
Quote
Quote
Quote
Or you could think ahead a little and bring your RDF file with you on a flash drive, or email it to yourself via an account that you specifically know the password for.
Come on - there is no perfect solution for something like this...

What if your PDA dies?
This shouldn't be a problem once you have the ability to import your rdf to the online version. You can store your rdf on an ftp and have assess to it without having to carry anything around.
My point exactly!
At the ATM?  (Or anywhere else you don't have a browser?)
(again, I'm thinking of PM as having all my secret info; not just passwords to web sites)

(Alan wonders how deeply we can nest quotes...   :)

Quote
Quote
And this helps how when you're at the airport ticket counter and you want to give them your frequent flyer number?
? You did bring your PDA with you, didn't you?
Absolutely!  It's *always* on my belt.  Unless I go for a run, or I'm in the shower.

Uh, I guess there are a few other times I don't have it directly on me, but it's close at hand...    :D


Quote
Quote
If PM is only to generate passwords, you're right. And if that's all it is, I'm in the wrong place. If it's (by intended design or evolution - or my gentle prodding and nudging smile.gif going to end up as a good place for all secret information, with syncing between computers and PDA, and the ability to fill in web pages - then I'm in the right place and just need to wait for it all to get there.

Ok, I've given this some thought - and the fact is, I really can't see how it would be all that difficult to add what you are asking for, and it really wouldn't impact the interface or anything much at all.
Yay!  I win!!!  :)

Quote
The simplest way I can think of to do this would be to add the concept of 'Account Type', with the default being 'OnLine' or 'Password' (meaning, a web or ftp based account), and a secondary being 'Info' or something like that. Then, when creating a new Account, if you choose 'Info' for the 'Type', basically all you would have is a big Comments field where you could type anything you want. Do I understand what you are asking for ok?

Even easier, I think.   Just always allow for a multi-line description and encrypt it.  (I'd be inclined to encrypt the whole record - why not? - but whatever's easier)

If you're generating passwords on-the-fly as now, you ignore the Description, or use it for notes or whatever   ("Joe said this was a good site for router info...")   not secret data, but it won't hurt if it's stored encrypted.  It's just a "notes" field then; just multi-line instead of one line as it is now.

And if I'm using the Description for my Secret Data (bank account info, PIN, etc) then I just ignore the password-generation settings for that account.

Really, all it needs is the multi-line description (I've got that for the dialog already, but need to rework the whole dialog with the tabs) and encrypting the description field.  Since Eric's got encryption for other fields (or will have it; not sure which) it's pretty simple to add it to the Description field (may need a flag; old descriptions are currently stored in clear; need to update the record with it encrypted - but again, no biggie; all invisible to the user)

So there's no need for an account "type" - it's all in how the user uses it.


Quote
I can see where this would be useful, but what I would suggest is write up a Feature Request, Post it, and see what happens. The worst that can happen is Eric will say no.
I thought I already had put it in as a feature request - yup, here it is:  
free-form text field on accounts (and groups?)

That thread leads off into Eric asking me to do some coding; I've started but haven't done Java or Javascript before, nor XUL (and little enough HTML and CSS) so I'm stumbling around a lot right now...   Now if you need a device driver, or hacking the innards of a machine I'm fine...   :)

Quote
Not at all - but you are doing something that I did once - asking for something that no one else seems to want or need - and getting frustrated by everyone's reluctance to jump on board all at once.
Well, geez - I just thought you were all as smart as I am, so you'd immediately see the brilliance of my ideas! :lol:  :lol:  :lol:  :lol:

Quote
Quote
Oh, my! Are you thinking the *servers* would sync amongst themselves? I supoose that's possible, but I wasn't thinking that - I was thinking I'd sync my *notebook* against server A, then server B, then server C...
Of course... that is how LDAP replication works - it is *strictly* a server-to-server synchronization - all an LDAP Client does is *read* from an LDAP server.
Ah, ok - different perception.  That certainly makes the client side much easer; probably worth it just for that.  And letting LDAP handle server-to-server is fine too; only maybe downside is it might be more difficult if someone wanted to set up their own server - but that's good too, in that it pushes towards using Eric's server (and revenue stream).

I think it'd be nice to have a change history, but that's just me being a detail junkie...  :)

Better brains than me have done this stuff - you're right on that; no need to reinvent the wheel unless it's bringing a big improvement.  (I also have a tendency to go architect something that's wonderfully beautiful - and complex - and someone'll say something like "well why don't we..." and I've completely missed the *obvious* and *simple* solution...   :)
(on the other hand, sometimes I'll see things nobody else does, so it goes both ways...  :)


- Al -

Offline tanstaafl

  • God Member
  • ******
  • Posts: 1363
Synch Settings
« Reply #22 on: October 10, 2005, 07:35:31 PM »
Quote
Of course... that is how LDAP replication works - it is *strictly* a server-to-server synchronization - all an LDAP Client does is *read* from an LDAP server.
Clarification:

Some LDAP Clients (but not all) *can* make changes to the LDAP directory server - but as far as I know, can only do so when connected, not in 'off-line' state.

Quote
That certainly makes the client side much easer; probably worth it just for that. And letting LDAP handle server-to-server is fine too; only maybe downside is it might be more difficult if someone wanted to set up their own server - but that's good too, in that it pushes towards using Eric's server (and revenue stream).
Good point, and one that is actually important to me. Eric deserves to make *millions* off of PM!! ;)

Offline Tyrantmizar

  • Sr. Member
  • ****
  • Posts: 307
Synch Settings
« Reply #23 on: October 10, 2005, 10:49:38 PM »
Added as "Sync settings" because ajw voted for it.

Since Eric hasn't given his complete support for this feature, whether or not that is a legitimate vote may be up to debate.  I'll leave that to the philosophers...
Tyrantmizar
- <a href="http://tyrantmizar.blogsome.com/">Check out my blog</a> (shameless plug :P)
- Lord of the Feature Requests / Enhancements Forum - BWAHAHAHAHA!!!!
- Lord of the other one, the [url=http://forums.passwordmaker.o

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Synch Settings
« Reply #24 on: October 10, 2005, 11:12:32 PM »
I see now that setting synchronization is very important. So it will be done, but probably with more manual intervention than people would want. This is the safest route. Anyway, it's quite a ways off so let's put the discussion on-hold until it's more relevent.

Offline tanstaafl

  • God Member
  • ******
  • Posts: 1363
Synch Settings
« Reply #25 on: October 11, 2005, 11:05:17 AM »
Okey dokey...

But, do are you considering this as separate from FTP Backup/Restore capability?

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Synch Settings
« Reply #26 on: October 11, 2005, 03:58:02 PM »
Yes.

Offline TaranQ

  • Normal Members
  • *
  • Posts: 1
Synch Settings
« Reply #27 on: June 30, 2006, 07:06:12 AM »
I am too Anxiously waiting for an option to merge data from one RDF to another.
I work at home and in office and if I don't keep them exactly in synch. Even if I have one or two different records I can't keep them in sync anymore. Wished there was an option to merge one RDF file with another, so records from both RDF's show up. And as I have no FTP space I prefer just manual and local merging.
That's really the only thing that's annoying me about passwordmaker.
The rest I enjoy very much, works fantastic!!
« Last Edit: June 30, 2006, 07:07:35 AM by TaranQ »

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Synch Settings
« Reply #28 on: June 30, 2006, 01:46:54 PM »
Thanks.

PasswordMaker Forums

Synch Settings
« Reply #28 on: June 30, 2006, 01:46:54 PM »