Proposal

[Günther "gue" Blaschek]

Hi folks,

I think I now have a solution that should cover all cases, while being both simple and backward-compatible with legacy approaches.

I therefore would like to make the following proposal. I'll start from scratch, as if no other solutions existed yet. After that, I'll shows how it affects producers and consumers. And finally, I'll make a suggestion how we can implement all this with a minimum of effort and changes to existing practice.

Let's start with a marker that I will call "OffRecord" for now. When a producer includes that in the clipboard, it does not want any consumers to record that. Historians and similar tools should simply ignore these clipboards, ideally by looking only at the flavors, without fetching the actual data.

How does this affect typical use cases?

1. Typinator- and TextExpander-like expansions:

save clipboard (content A)

fill clipboard (with OffRecord), paste

... (possibly repeated multiple times)

restore clipboard (A + OffRecord)

Historians will ignore the entire sequence. The last "official" clipboard contents that they saw is A, and this is still there at the end of the sequence.

2. Macro tool or similar utility:

fills the clipboard with new content.

The producer must decide whether the new content should appear in a clipboard history or not. Depending on this decision, it should include OffRecord or not.

3. Password utility:

If the tool puts things on the clipboard that should not show up in any clipboard history, they should simply include OffRecord. This applies to passwords, credit card numbers and secret notes alike.

There is only one situation where an additional marker is needed: When a history tool (or similar, like the good old scrapbook) restores an OLDER version of the clipboard, it can include a RestoredType marker, where the data should indicate the source (TBD: how; which change count; how to deal with data from older sessions?)

Note that the RestoredType marker should normally NOT be used in a sequence of "OffRecord" clips, where the last restores the state immediately before the sequence.

The RestoredType marker will be useful when one or more clipboard utilities coexist. When one of them restores older content, it can tell the others about the fact. All other utilities can safely ignore RestoredType markers. For example, when Typinator would save a clipboard with a RestoredType marker, it would later restore that clipboard as it was, including the RestoredType marker (and plus an additional OffRecord marker). This means that clipboard utilities should first check for OffRecord and check for RestoredType only if OffRecord is missing.

When a historian temporarily uses the clipboard for pasting a previous copy of the clipboard, it does NOT need to mark that with RestoredType. Instead, it should save the clipboard, paste the older clipboard with the OffRecord flag, and then restore the original clipboard, again with OffRecord.

That's it. In my opinion, OffRecord and RestoredType should suffice. In particular, AutoGeneratedType should be dropped. Likewise, ConcealedType is not needed, as OffRecord covers that, too.

This brings us to the question how OffRecord should actually be represented. Instead of introducing yet another type, I would propose to use org.nspasteboard.TransientType for this, even though the name is misleading. The point is that this flavor is already established and has been used for a while. The semantics may be slightly different, but in my opinion, the TransientType marker has been used in this sense, anyway.

Typinator would continue to use the legacy flavors (in particular, "Pasteboard generator type") along with "org.nspasteboard.TransientType", and other producers will probably do the same. This should not create any conflicts.

To summarize:

• org.nspasteboard.TransientType shall be used to tell other utilities not to save this clipboard content.
  
• org.nspasteboard.RestoredType shall be used to tell other utilities that the current clipboard content is a copy of older content.
  
• When both org.nspasteboard.TransientType and org.nspasteboard.RestoredType are present, the latter shall be ignored. 
• org.nspasteboard.AutoGeneratedType and org.nspasteboard.ConcealedType shall be dropped.
  
• Clipboard contents with the org.nspasteboard.TransientType flavor can be anything, including empty. Consumers must not expect any particular content.
• Clipboard contents with the org.nspasteboard.RestoredType flavor shall identify the original version of the clipboard data. The exact content is to be defined.
  

Questions to all participants:

• Would this work for you?
  
• Do you need additional information?
  
• Would this break your existing code?
  
• What should be contained in a RestoredType marker?
  

Cheers,

gue

[Thomas Tempelmann]

On Mon, Jun 17, 2013 at 3:11 PM, Günther "gue" Blaschek <gue...@gmail.com> wrote:

That's it. In my opinion, OffRecord and RestoredType should suffice. In particular, AutoGeneratedType should be dropped. Likewise, ConcealedType is not needed, as OffRecord covers that, too.

Thats somewhat agreeable.

 

This brings us to the question how OffRecord should actually be represented. Instead of introducing yet another type, I would propose to use org.nspasteboard.TransientType for this, even though the name is misleading. The point is that this flavor is already established and has been used for a while. The semantics may be slightly different, but in my opinion, the TransientType marker has been used in this sense, anyway.

Yes, and that's also pretty close to the semantics we already had at the start of the discussion :)

 

• When both org.nspasteboard.TransientType and org.nspasteboard.RestoredType are present, the latter shall be ignored. 
• org.nspasteboard.AutoGeneratedType and org.nspasteboard.ConcealedType shall be dropped.

With that, I would even go as far as saying: Let's rename RestoredType into AutoGeneratedType. Because, in a way, what we want to use restored content for is generated - not really auto generated, but close enough.

--
Thomas Tempelmann

Irradiated Software

[Peter Maurer]

> To summarize:
> • org.nspasteboard.TransientType shall be used to tell other utilities not to save this clipboard content.
> • org.nspasteboard.RestoredType shall be used to tell other utilities that the current clipboard content is a copy of older content.
> • When both org.nspasteboard.TransientType and org.nspasteboard.RestoredType are present, the latter shall be ignored.
> • org.nspasteboard.AutoGeneratedType and org.nspasteboard.ConcealedType shall be dropped.
> • Clipboard contents with the org.nspasteboard.TransientType flavor can be anything, including empty. Consumers must not expect any particular content.
> • Clipboard contents with the org.nspasteboard.RestoredType flavor shall identify the original version of the clipboard data. The exact content is to be defined.

This would mean that security-sensitive pasteboards (the kind of pasteboard one would mark as "concealed") would never get recorded, right?

Speaking as a user, no, this wouldn't work for me -- there are situations where I want that kind of content on my pasteboard history, e.g., when filling out a flash-based form where the keychain doesn't work.

I don't feel strongly about AutogeneratedType either way, but to keep things simple, I'll just stick to my vote for Peter N Lewis's suggestion. :)

Cheers,

Peter.

[Thomas Tempelmann]

Oh, to clarify my favorite solution:

I'd be all in for widening the meaning of "TransientType" the way Günther suggested.

I also like to keep AutoGeneratedType, with what Günther suggested for RestoredType. AutoGeneratedType's old semantics were close enough to what I wanted to use RestoredType for.

Lastly, I agree with Peter that we should have a separate type for passwords. Not only for the reason Peter gives, but also as a signal to the world (e.g. the 1pw guys) that there is now a specific type for that, and not just a side-effect of something existing.

Thomas

[Peter N Lewis]

On 17/06/2013, at 21:11 , Günther gue Blaschek <gue...@gmail.com> wrote:
> 2. Macro tool or similar utility:
> fills the clipboard with new content.
> The producer must decide whether the new content should appear in a clipboard history or not. Depending on this decision, it should include OffRecord or not.

If the clipboard is not going to be restored, then using the OffRecord would break my invariant, so this would not work well for my use. If the sequence was the same as for text expansion (ie, set the clipboard, then restore the clipboard), then using OffRecord would be fine. Keyboard Maestro never does this, but a macro tool that does might use this sequence.

> 3. Password utility:
> If the tool puts things on the clipboard that should not show up in any clipboard history, they should simply include OffRecord. This applies to passwords, credit card numbers and secret notes alike.

This would not work well for me for two reasons. First, I often want the password in my clipboard history - I want to be able to copy the username and password, and then paste both. Second, it would break my invariant that the clipboard matches the last non-OffRecord value.

Breaking the invariant is a big problem as far as I am concerned, because it means the clipboard history that the user looks at does not match what the user gets when they Paste. I am highly committed to this invariant, and can't accept any solution that breaks it. The last thing in the clipboard history must (for my purposes) match the current clipboard value.
Peter.


--
Keyboard Maestro 6.0.1 now out - Syncing, Plug Ins, Styled Text, Browser Control & More.

Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<http://www.stairways.com/> <http://download.keyboardmaestro.com/>

[Thomas Tempelmann]

Peter N. Lewis wrote:

> If the clipboard is not going to be restored, then using the OffRecord would
> break my invariant, so this would not work well for my use. If the sequence
> was the same as for text expansion (ie, set the clipboard, then restore the
> clipboard), then using OffRecord would be fine. Keyboard Maestro never does
> this, but a macro tool that does might use this sequence.

How about adding specific data to the OffRecord type for this? Something
that says "this is the restored content after having placed transient data
into the clipboard".

[Brian Bucknam]

On Monday, June 17, 2013 6:11:51 AM UTC-7, Günther "gue" Blaschek wrote:

[… Good details …]

To summarize:

• org.nspasteboard.TransientType shall be used to tell other utilities not to save this clipboard content.
  
• org.nspasteboard.RestoredType shall be used to tell other utilities that the current clipboard content is a copy of older content.
  
• When both org.nspasteboard.TransientType and org.nspasteboard.RestoredType are present, the latter shall be ignored. 
• org.nspasteboard.AutoGeneratedType and org.nspasteboard.ConcealedType shall be dropped.
  
• Clipboard contents with the org.nspasteboard.TransientType flavor can be anything, including empty. Consumers must not expect any particular content.
• Clipboard contents with the org.nspasteboard.RestoredType flavor shall identify the original version of the clipboard data. The exact content is to be defined.
  

Questions to all participants:

• Would this work for you?
  
• Do you need additional information?
  
• Would this break your existing code?
  
• What should be contained in a RestoredType marker?
  

Sorry for the long delay in replying, but I have been traveling, and working on other stuff.

It is strange that in the other discussion thread, where RestoredType was proposed, it seemed that RestoredType was falling out of favor, but here it seems not to be "too bad" -- maybe we are all just tired of the discussion.

I think this proposal works or can work for everyone, and makes sense, with the exception that I find ConcealedType too useful-seeming to drop, and as both Peters have pointed out, it is not at all equivalent to TransientType (OffRecord).

Perhaps after this break, we can actually find a consensus?

Cheers,

Brian

[Peter N Lewis]

On 07/07/2013, at 9:34 , Brian Bucknam <br...@smilesoftware.com> wrote:
> I think this proposal works or can work for everyone, and makes sense, with the exception that I find ConcealedType too useful-seeming to drop, and as both Peters have pointed out, it is not at all equivalent to TransientType (OffRecord).

For the record, I have added support for concealing passwords to Keyboard Maestro 6.1, and it honours the ConcealedType now (as well as making a valiant (though somewhat doomed and futile) effort to detect things that look like passwords). I think it should be in there, whether we can ever get 1Password or anyone else to support it.

> Perhaps after this break, we can actually find a consensus?

Shrug. I've put forward a set or specs, my requirements, and reasoning behind it, but there always seems to be disagreement on significant aspects of any proposed spec. Has this changed?
Peter.


--
I will have sporadic access to email for the next week or so, sorry for any delays.


Keyboard Maestro 6.1 now out - set web checkboxes & radio buttons, exit from loops, and more.

[Günther "gue" Blaschek]

On Sunday, July 7, 2013 3:34:08 AM UTC+2, Brian Bucknam wrote:

[snip]

I think this proposal works or can work for everyone, and makes sense, with the exception that I find ConcealedType too useful-seeming to drop, and as both Peters have pointed out, it is not at all equivalent to TransientType (OffRecord).

Perhaps after this break, we can actually find a consensus?

As far as I am concerned, TransientType would be all I need, if we can agree that such clipboards are ignored by historians.

If anybody has further requirements beyond that (RestoredType, ConcealedType), please pick up one of the earlier proposals (by Peter Lewis and me) and modify/extend it as needed.

As the next step, everyone should check whether the revised proposal fits his needs. Maybe this brings us forward?

I promise that I will no longer criticize misleading names. :-)

gue