Menu
▾
▴
trike-devel — Internal mailing list for development discussions.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(22) |
Feb
(31) |
Mar
(16) |
Apr
(8) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|
From: Eleanor S. <el...@dy...> - 2019-11-21 00:04:31
|
Hi all! Apologies for the delay in response — was traveling and then various things caught fire while I was gone. The AUTHORS certificate model looks great! Let's definitely do that everywhere. I would tenatively suggest, re: main copyright holders, that it makes sense for Brenda's LLC to own the Smalltalk repo and my LLC to own the Python repo. However, I'd ideally like the rights on the methodology as distinct from its embodiments to be retained by individuals — I totally don't care if the code gets sold as a corporate asset at some point, but the ideas are a different story. Now, from a legal perspective, I'm not sure how that actually happens, but I'd suggest that we say that the documentation copyright for the methodology (as opposed to an implementation) be held separately. It should also probably be retained under a documentation-centric license that understands things like the moral rights of the author. Does that overcomplicate things enough? E. On 2019.10.31 17:36, Bren wrote: > A while back, Ben Lipton hooked us up with a Jekyll site build behind > our existing content and look & feel. Now, as soon as I debug what's > wrong with our branch permissions and add any other past > developers/theorists who want (*cough* Steph? *cough*), we can all > edit the website on GitHub. Whoo hoo! > > Now, I'm poking the content a little, trying to fix or remove broken > links, finish as much of a move from SourceForge to GitHub as we're > making, and update things that are no longer correct. We have some > copyright & licensing issues we should hammer out, and I figure we may > as well talk about both the code and the website at the same time. > > What we have: > - CC by-nc-sa on the v1 paper > - MIT license with arbitrarily named non-legal entity on the website > (maybe more than one?), presumably to apply to website content > - Copyrights various dates & holders, omitting at least one person > (Ben), in the website footers > - MIT license, copyright various dates & contributors, in various > GitHub repos that contain the v1 Smalltalk code (it was in individual > class comments, but I consolidated that already) > - A possibly serious licensing issue with the released pre-built > versions of v1, in that we bundled Squeak, which at the time was > licensed Squeak-L, which (I later became aware) had murky legal status > regarding whether we are allowed to redistribute it in a bundle > - Some possibly serious licensing issues in one v1 repository > (Octopus-Patches), in that it contains code from multiple developers > outside our project, for at least some of which I couldn't find > origins, licenses, or developer contact information; fortunately this > is Squeak-specific code I think we shouldn't need in the future > > What I suggest (based heavily on > https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html): > - Note the licensing issues with v1 on the tools page and in the > Octopus-Patches repo, so that people with licensing concerns can avoid > using v1. > - Use the MIT license with an AUTHORS certificate > (https://github.com/berneout/authors-certificate) approach (minus the > npm-specific parts) for all code repos moving forward. I don't want > to require developers to put anything more than their name & company > (if their company could conceivably have rights to their work) in the > AUTHORS file, though; I tried very hard not to leak PII that wasn't > already leaked when I ported the code to GitHub. This will require > all past contributors (not many; looks like me, Ella & Steph) to get a > GitHub account & add themselves. I'd want to wait until I finish > consolidating repos, though, because I keep needing to rebase & also > maybe we could have a smaller number. Possibly even just one. > - Choose an entity or entities to be listed in the actual LICENSE as > the main copyright-holder (with others listed in the AUTHORS file). > This is where I especially need help. It sounds like using an > independent non-profit association would be most awesome, but we don't > have one, and I suspect none of us want to start one. I have an LLC > we could use, but I don't want to use it if it makes anyone else > uncomfortable. Or, we could use me & Ella as individuals, or I > suppose just me for the Smalltalk repo and just Ella for the Python repo. > - State explicitly on the website that the website is "associated > documentation files" for Trike, therefore putting it under the MIT > license (but with its own copy of the same LICENSE file, and likely > different AUTHORS than the other Trike repo(s)). > - Continue to put explicit licenses that are appropriate for documents > on standalone documents like the paper. > > How do y'all feel about this problem, this solution, the options for > copyright holders, getting mail from a list that hasn't seen any > traffic in years (expect more), ...? > > --B > > > _______________________________________________ > Trike-devel mailing list > Tri...@li... > https://lists.sourceforge.net/lists/listinfo/trike-devel -- Ideas are my favorite toys. |
|
From: Bren <asp...@hh...> - 2019-11-08 04:57:41
|
I'm finally done digging up old code and combining repositories, therefore also done rebasing. It's now safe to fork https://github.com/octotrike/trike. You can even use the working-for-me build instructions to load the (few) modules that load, and watch the tests pass! Don't get too excited, though: there's no UI and I haven't even ripped the v1 cruft out of the model, much less added the rest of v2. Since I'm the only one actively coding right this second, pull or merge requests seemed self-referential, and I just pushed to both pharo (the main dev branch) and default (the equivalent of trunk or master). If any other Smalltalk types are lurking and have bandwidth for code review or contributions, please let me know; I'd love some of either or both. Bren P.S. I bumped the copyright year but put the new year copyright me as an individual contributor pending discussion of my previous post; I'll change to whatever we agree on but I didn't want to hold up development. |
|
From: Bren <asp...@hh...> - 2019-10-31 15:54:07
|
A while back, Ben Lipton hooked us up with a Jekyll site build behind our existing content and look & feel. Now, as soon as I debug what's wrong with our branch permissions and add any other past developers/theorists who want (*cough* Steph? *cough*), we can all edit the website on GitHub. Whoo hoo! Now, I'm poking the content a little, trying to fix or remove broken links, finish as much of a move from SourceForge to GitHub as we're making, and update things that are no longer correct. We have some copyright & licensing issues we should hammer out, and I figure we may as well talk about both the code and the website at the same time. What we have: - CC by-nc-sa on the v1 paper - MIT license with arbitrarily named non-legal entity on the website (maybe more than one?), presumably to apply to website content - Copyrights various dates & holders, omitting at least one person (Ben), in the website footers - MIT license, copyright various dates & contributors, in various GitHub repos that contain the v1 Smalltalk code (it was in individual class comments, but I consolidated that already) - A possibly serious licensing issue with the released pre-built versions of v1, in that we bundled Squeak, which at the time was licensed Squeak-L, which (I later became aware) had murky legal status regarding whether we are allowed to redistribute it in a bundle - Some possibly serious licensing issues in one v1 repository (Octopus-Patches), in that it contains code from multiple developers outside our project, for at least some of which I couldn't find origins, licenses, or developer contact information; fortunately this is Squeak-specific code I think we shouldn't need in the future What I suggest (based heavily on https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html): - Note the licensing issues with v1 on the tools page and in the Octopus-Patches repo, so that people with licensing concerns can avoid using v1. - Use the MIT license with an AUTHORS certificate (https://github.com/berneout/authors-certificate) approach (minus the npm-specific parts) for all code repos moving forward. I don't want to require developers to put anything more than their name & company (if their company could conceivably have rights to their work) in the AUTHORS file, though; I tried very hard not to leak PII that wasn't already leaked when I ported the code to GitHub. This will require all past contributors (not many; looks like me, Ella & Steph) to get a GitHub account & add themselves. I'd want to wait until I finish consolidating repos, though, because I keep needing to rebase & also maybe we could have a smaller number. Possibly even just one. - Choose an entity or entities to be listed in the actual LICENSE as the main copyright-holder (with others listed in the AUTHORS file). This is where I especially need help. It sounds like using an independent non-profit association would be most awesome, but we don't have one, and I suspect none of us want to start one. I have an LLC we could use, but I don't want to use it if it makes anyone else uncomfortable. Or, we could use me & Ella as individuals, or I suppose just me for the Smalltalk repo and just Ella for the Python repo. - State explicitly on the website that the website is "associated documentation files" for Trike, therefore putting it under the MIT license (but with its own copy of the same LICENSE file, and likely different AUTHORS than the other Trike repo(s)). - Continue to put explicit licenses that are appropriate for documents on standalone documents like the paper. How do y'all feel about this problem, this solution, the options for copyright holders, getting mail from a list that hasn't seen any traffic in years (expect more), ...? --B |
|
From: Eleanor S. <el...@dy...> - 2015-05-26 16:36:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015.05.26 17.40, Lou...@be... wrote: > Hi, > > Is Trike dead ? The last updates were all done in 2012. Definitely not! There's some work underway to build a new version of the native client and a lot of interesting research plans that will, one way or another, be born out. I haven't posted anything about it here yet because it's not quite solid enough to talk about yet, but I'll let folks know when it is. E. - -- Ideas are my favorite toys. -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAlVknUIACgkQQwkE2RkM0wqb1gD/Q1fbF5hnPGwbec8s+kp2atXG w2Un1TBuOFUEzv+EPAUA/3AqQiMwFMavaUGKjHAnyC6BOQvzenbCYMm+mjLt1WUN =WVch -----END PGP SIGNATURE----- |
|
From: <Lou...@be...> - 2015-05-26 14:55:26
|
Hi, Is Trike dead ? The last updates were all done in 2012. Louis Nadeau | Manager, Product Security, CORP-IT Infrastructure Bentley Systems Incorporated Bentley Canada, Inc. 3365 Boulevard Ste-Anne Beauport, Quebec G1E 3L1 Canada Tel: +1-418-666-7691, ext 269 Email: <mailto:Lou...@be...> Lou...@be... |
|
From: Eleanor S. <el...@dy...> - 2012-08-20 01:44:08
|
Discussed:
* Project management
* Getting booted up for Agile
* What roles we need to fill to get dev work started and to ship a thing
* What tasks we need to get unblocked to get dev work started
Todo list dependency management
Agile user story backlog tracking
Data model information repo
Bug tracking data
* General tracks of work:
Theory
Code
PM
Action items:
B to start unravelling dependencies on her local-only tracker
E to look for someone to help reboot our dev process
B to consolidate all code to a common publicly accessible location
E.
--
Ideas are my favorite toys. |
|
From: Brenda L. <asp...@hh...> - 2012-08-17 19:36:21
|
My best guess is that SourceForge changed their Apache configs to stop looking for home.shtml. I added a symlink from index.shtml, and it's up again. Or, possibly I'd had one there earlier, overwrote it during recent site updates, then a cached copy prevented me from noticing the breakage. The good news is, it was only the splash page that was down; deeper links (e.g. the tools page) were working the whole time. Feedback on the revised site would still be useful. Specifically, can people find what they need now? And, is it clear what Trike is? Those are the two main things I was trying to fix. --B |
|
From: Eleanor S. <el...@dy...> - 2011-05-16 12:07:19
|
A conversation this past week has convinced me that we need to look at degredation, not just failure, as a framework, and that we should consider thinking about the role of time in the systems we look at. This is probably an in-person conversation. E. -- Ideas are my favorite toys. |
|
From: Eleanor S. <el...@dy...> - 2011-05-07 10:38:40
|
On 2011.05.05 07.48, Brenda Larcom wrote: > On May 4, 2011, at 4:21 PM, Eleanor Saitta wrote: >> Mid-June sounds reasonable for me, too. We'll hopefully be seeing >> each other in person the 17th-19th, for Toorcon Seattle, and could >> maybe plan a little time in person right after that, even if it's >> just a day or two. > > Sounds appealing. Putting in our first 10 hours together would > really help. Time in Seattle would make me happier than time in > Phoenix (although extending that visit a few days & putting in our > second 10 hours together would also be good). Perhaps I? we? should > work on some sort of talk submission to ensure this Seattle thing > happens... We should work on some kind of talk submission. I'm planning on going either way, but one or both of us should submit something. I'd like to, ideally, get submissions out to three or four security cons this year personally, although I'm going to be concentrating on the European side. Cons seem to generally be ok with talk repeats off-continent, so we may be able to extend the mileage of our talks a bit that way. :-) > Yarg. The list of links/intro materials I found before is on > http://trike.wiki.sourceforge.net/, I think under Development > Environment or similar, but apparently SourceForge, or maybe my evil > ISP, doesn't like me right now. If you want to do something > amazingly useful (but of unknown difficulty), I have an ideas > myself: - Get Squeak 4.2 - Open the SqueakMap Package Loader - > Install Connectors - Figure out how to create any Connectors object > with a different shape/that looks different from the ones that > already exist That sounds a bit rough right now. I think what I want is to write some toy with a bit of an object model that hits some web service or something, just so I get to poke around various things. > I'm also perfectly happy to have you start from wherever you are > right now (only in June) & have us do some pair programming on Trike > itself. I'd like to have the language more in my head, because while in the past this has resulted in stuff getting done, it hasn't resulted in me becoming as self-sufficient as I'd like. > I'll send you some links (or maybe a hard copy book) on Agile stuff, > too. At this moment I feel like us both grokking that would be more > useful than us both grokking Squeak; Squeak is easily transmitted > inside the Agile framework. Hrm, ok, sure. I'd like a bit of both, personally, but I'll take your word on this. Softcopy required if you want me to read it before June, because even if you want to try to catch me with a book, I'm out of luggage space. E. -- Ideas are my favorite toys. |
|
From: Eleanor S. <el...@dy...> - 2011-05-07 10:24:32
|
On 2011.05.05 07.53, Brenda Larcom wrote: > svn up Oh, wow, help got a ton bigger since I last read it. Thanks much, this is very useful. > On May 4, 2011, at 7:40 AM, Eleanor Saitta wrote: >> Entire spreadsheet: o What actions will break the spreadsheet? > > I don't have an explicit list indexed in this way, but check out the > Care & Feeding section on the Help tab. Does this have what you are > after, the kind of thing you are after, is it usable, and if not, can > you suggest a way to refactor it? In fact, I have those same > questions about all your questions. :) It is what I was looking for and is useful! The help tab is kind of long right now, which makes it a bit hard to read, but otherwise, awesome. Maybe we should break out the individual tab help sections onto separate tabs? Especially the actors one is quite long, and that would make the amount of information that's there a bit more obvious and make people like me read it more reliably. >> Connections tab: o What does "shared" mean? o Do the from/to/OSI >> layer/traverses/protocol columns matter? For what? > > Tired. Will address in my next documentation marathon. No worries; this was one of the things I didn't actually need answered now anyway. >> * The to and from targets are misformatted/whited out > I can't reproduce this. Can you send me/point me to an example? > Also, let me know which version of Excel you're using, on which > platform; it could be a compatibility problem. I'll send you something internally; it has client data in it. >> Protocols tab: o What is this tab for? > I added a somewhat cheesy quick blurb for this tab on the Help tab. > I suspect you want more, but what? Why are we capturing this data and how do we (intend) to use it. >> Threats tab: * Can we have an "nonsenical" marking, instead of just >> ignoring it in the security objectives? > > It's possible you could convince me otherwise, but right now, my > answer is nope. The nonsensical threats are supposed to be greyed > out already due to all the flags & type settings on the other tabs. > If they aren't, then as of this moment I think [at least] one of the > following is true: - There is a bug in the model (i.e. flags and/or > type settings are set incorrectly for some actor or data). - There is > a bug in the spreadsheet (i.e. I failed to grey something out that > oughta be greyed out). - There is a bug or omission in the > methodology (e.g. we aren't modeling something we oughta model). Let's go over the example I'm sending you and see what you think; I may have mis-marked something. > I don't have a consolidated list, but every time you see the word > FUTURE in the Help, you will know that bit isn't true yet. I think a consolidated list would be good, at some point. > Done, except I put it on the Help tab. Works? Of course. Thanks much! E. -- Ideas are my favorite toys. |
|
From: Eleanor S. <el...@dy...> - 2011-05-07 01:25:24
|
http://www.husdal.com/2011/05/03/supply-chain-vulnerability-and-resilience/ http://www.husdal.com/2011/05/04/creating-the-resilient-supply-chain/ Also, we should talk about this idea of the "shape" of a failure at some point. Not sure if it's got legs or not. E. -- Ideas are my favorite toys. |
|
From: Brenda L. <asp...@hh...> - 2011-05-05 07:08:49
|
svn up :) On May 4, 2011, at 7:40 AM, Eleanor Saitta wrote: > Entire spreadsheet: > o What actions will break the spreadsheet? I don't have an explicit list indexed in this way, but check out the Care & Feeding section on the Help tab. Does this have what you are after, the kind of thing you are after, is it usable, and if not, can you suggest a way to refactor it? In fact, I have those same questions about all your questions. :) > o What are the applicability columns for? Added this answer in the Help about the Actors tab, which tab is where these column names are defined. > Actor tab: > o What do "favored user", "authenticated", "attacker", and (especially) > "uses system", "used by system", "shared", and "shared resources" > imply? > o What are the privileges columns for and how do they work? > Data Model tab: > o What do "shared" and "transient" mean? Added these answers in the Help about these tabs. > Intended Actions tab: > o Where do we specify the rules for "conditional"? Hah! Finally one I had already addressed (sort of; I had written it in the Help tab I hadn't released yet). The answer is buried in the Help about what yellow means in the Intended Actions tab section. > Connections tab: > o What does "shared" mean? > o Do the from/to/OSI layer/traverses/protocol columns matter? For > what? Tired. Will address in my next documentation marathon. > * The to and from targets are misformatted/whited out I can't reproduce this. Can you send me/point me to an example? Also, let me know which version of Excel you're using, on which platform; it could be a compatibility problem. > Protocols tab: > o What is this tab for? I added a somewhat cheesy quick blurb for this tab on the Help tab. I suspect you want more, but what? > Threats tab: > * Can we have an "nonsenical" marking, instead of just ignoring it in > the security objectives? It's possible you could convince me otherwise, but right now, my answer is nope. The nonsensical threats are supposed to be greyed out already due to all the flags & type settings on the other tabs. If they aren't, then as of this moment I think [at least] one of the following is true: - There is a bug in the model (i.e. flags and/or type settings are set incorrectly for some actor or data). - There is a bug in the spreadsheet (i.e. I failed to grey something out that oughta be greyed out). - There is a bug or omission in the methodology (e.g. we aren't modeling something we oughta model). > o What do the different severity levels affect? > Security Objectives tab: > o What should populate the "prohibited threats" and "initial > configuration" columns? > Use Case Details: > o What goes in the "choice", "terminal", "variation", and "attacker > influenced", columns? Tired. Will address in my next documentation marathon. > I know some of the above are for things which aren't hooked up yet, > which is fine, but we should have a list somewhere in the help of which > bits of data aren't hooked up/fully factored. I don't have a consolidated list, but every time you see the word FUTURE in the Help, you will know that bit isn't true yet. > Also, we should put a > spreadsheet version number in the System Overview tab, so we can tell if > we're using a current revision of the spreadsheet/what problems a > spreadsheet is likely to have, Done, except I put it on the Help tab. Works? > and probably start keeping a changelog, > possibly also in the help. Good idea. Next marathon. --B |
|
From: Brenda L. <asp...@hh...> - 2011-05-05 06:49:52
|
On May 4, 2011, at 4:21 PM, Eleanor Saitta wrote: > Mid-June sounds reasonable for me, too. We'll hopefully be seeing each > other in person the 17th-19th, for Toorcon Seattle, and could maybe plan > a little time in person right after that, even if it's just a day or > two. Sounds appealing. Putting in our first 10 hours together would really help. Time in Seattle would make me happier than time in Phoenix (although extending that visit a few days & putting in our second 10 hours together would also be good). Perhaps I? we? should work on some sort of talk submission to ensure this Seattle thing happens... > I should have some slack time starting next week where I could > conceivably do some code-related stuff as well as working on diagrams > and the like, so maybe you should take another poke at pointing me at > some squeak intro stuff, and I'll try to come up with some problem I > want to write some code for, to warm up. Yarg. The list of links/intro materials I found before is on http://trike.wiki.sourceforge.net/, I think under Development Environment or similar, but apparently SourceForge, or maybe my evil ISP, doesn't like me right now. If you want to do something amazingly useful (but of unknown difficulty), I have an ideas myself: - Get Squeak 4.2 - Open the SqueakMap Package Loader - Install Connectors - Figure out how to create any Connectors object with a different shape/that looks different from the ones that already exist I'm also perfectly happy to have you start from wherever you are right now (only in June) & have us do some pair programming on Trike itself. I'll send you some links (or maybe a hard copy book) on Agile stuff, too. At this moment I feel like us both grokking that would be more useful than us both grokking Squeak; Squeak is easily transmitted inside the Agile framework. --B |
|
From: Eleanor S. <el...@dy...> - 2011-05-04 23:21:48
|
On 2011.05.04 23.59, Brenda Larcom wrote: > This is an awesome list of questions - thanks! I'll take a stab at > answering these shortly. Yay! None of them are urgent for this go-round for me, but about 2/3s of them I really would like answers to, for me, too. > In other news, I have Connectors working in Squeak 4.2. I am working > on getting Genie working as well; there's a bug filed in Squeak's > mantis that I'm working from, but the suggested fix doesn't work for > me yet. Woot! > Also, I've been doing some reading & I think it's time to ramp up our > supposed Agile development process & get more serious about it. > There's a lot of there there, but I feel like it would help us get > moving & actually deliver a proper new release. Not getting any code > out in years is driving me crazy. My theory goes, if we both put in > 10 hours a week together every week, we could do the equivalent of 1 > week's work, i.e. 1 iteration, in a month. Is it conceivable? On my > end, I could start in about mid-June. Mid-June sounds reasonable for me, too. We'll hopefully be seeing each other in person the 17th-19th, for Toorcon Seattle, and could maybe plan a little time in person right after that, even if it's just a day or two. I should have some slack time starting next week where I could conceivably do some code-related stuff as well as working on diagrams and the like, so maybe you should take another poke at pointing me at some squeak intro stuff, and I'll try to come up with some problem I want to write some code for, to warm up. E. -- Ideas are my favorite toys. |
|
From: Brenda L. <asp...@hh...> - 2011-05-04 23:14:06
|
On May 4, 2011, at 7:40 AM, Eleanor Saitta <el...@dy...> wrote: > Going from the latest version on octotrike.org, here's some stuff that > we need more help around: This is an awesome list of questions - thanks! I'll take a stab at answering these shortly. In other news, I have Connectors working in Squeak 4.2. I am working on getting Genie working as well; there's a bug filed in Squeak's mantis that I'm working from, but the suggested fix doesn't work for me yet. Also, I've been doing some reading & I think it's time to ramp up our supposed Agile development process & get more serious about it. There's a lot of there there, but I feel like it would help us get moving & actually deliver a proper new release. Not getting any code out in years is driving me crazy. My theory goes, if we both put in 10 hours a week together every week, we could do the equivalent of 1 week's work, i.e. 1 iteration, in a month. Is it conceivable? On my end, I could start in about mid-June. > --B |
|
From: Eleanor S. <el...@dy...> - 2011-05-04 17:18:19
|
Going from the latest version on octotrike.org, here's some stuff that we need more help around: Entire spreadsheet: o What actions will break the spreadsheet? o What are the applicability columns for? Actor tab: o What do "favored user", "authenticated", "attacker", and (especially) "uses system", "used by system", "shared", and "shared resources" imply? o What are the privileges columns for and how do they work? Data Model tab: o What do "shared" and "transient" mean? Intended Actions tab: o Where do we specify the rules for "conditional"? Connections tab: o What does "shared" mean? o Do the from/to/OSI layer/traverses/protocol columns matter? For what? * The to and from targets are misformatted/whited out Protocols tab: o What is this tab for? Threats tab: * Can we have an "nonsenical" marking, instead of just ignoring it in the security objectives? o What do the different severity levels affect? Security Objectives tab: o What should populate the "prohibited threats" and "initial configuration" columns? Use Case Details: o What goes in the "choice", "terminal", "variation", and "attacker influenced", columns? This is a combination of things that I don't understand at the moment and questions which I think someone else would have. I'm assuming here that someone gets the basics of what an actor, asset, etc., is, which obviously isn't true in general, but that's a different level of docs. I know some of the above are for things which aren't hooked up yet, which is fine, but we should have a list somewhere in the help of which bits of data aren't hooked up/fully factored. Also, we should put a spreadsheet version number in the System Overview tab, so we can tell if we're using a current revision of the spreadsheet/what problems a spreadsheet is likely to have, and probably start keeping a changelog, possibly also in the help. E. -- Ideas are my favorite toys. |
|
From: Brenda L. <asp...@hh...> - 2010-11-13 06:40:02
|
I wrote up some conventions that I think will fix the robustness, maintainability, portability, & usability issues we've seen with the spreadsheet so far, as much as is possible given that it's still a spreadsheet. I am planning to re-implement the spreadsheet using these conventions in the next couple of weeks, because I need to release it before my talk at BayThreat at the beginning of December. So, if you have anything to add, now would be a great time. :) Also, if you have some versions of Excel or OpenOffice or any other spreadsheet program that aren't shown in the color portability spreadsheet I attached to the wiki page, please extend the color portability spreadsheet to show those as well. https://sourceforge.net/apps/trac/trike/wiki/Spreadsheet%20Construction%20Conventions --B |
|
From: Eleanor S. <el...@dy...> - 2010-08-20 13:46:02
|
This article is a little unclear, and I think the author is a bit too fond of his analogies, but he's definitely saying some things that veer toward the sensible side of things. It might be worth digging a bit into what they're doing at some point. https://www.infosecisland.com/blogview/6646-Better-Security-Through-Sacrificing-Maidens.html /Ella -- Ideas are my favorite toys. |
|
From: Brenda L. <asp...@hh...> - 2010-08-20 09:02:46
|
I checked in a new Trike spreadsheet. As usual, you can get it at http://trike.svn.sourceforge.net/viewvc/trike/trunk/src/Trike.xlsx . Among other things, it is an attempt to fix the compatibility problems between Excel 2009 (where I wrote it), other versions of Excel, and OpenOffice. Please holler if colors look off, or do not seem to be updating accurately, and mention the OS and spreadsheet software you tried with. -- B |
|
From: Eleanor S. <el...@dy...> - 2010-07-13 00:52:04
|
On Mon, Jul 12, 2010 at 02:17:18PM -0700, Brenda Larcom wrote: > One of my clients just gave me an architecture document that uses it. So > far it looks like a very interesting thing. In particular, I suspect that > each element of a threat model should cover one of these boxes. It might > give us language for discussing the appropriate level of abstraction for > each element we need. Of course since this is the first time I've heard of > it, it may take longer to explain the framework than it is worth. Huh, that's fascinating. I'm not sure if it's something that should end up being a part of how we talk about our work externally, but it looks like it should be useful internally for evaluating how our models fit together. /Ella -- All things in moderation, including moderation. |
|
From: Brenda L. <asp...@hh...> - 2010-07-12 21:31:03
|
Hi guys, Check this out: http://en.wikipedia.org/wiki/Zachman_Framework One of my clients just gave me an architecture document that uses it. So far it looks like a very interesting thing. In particular, I suspect that each element of a threat model should cover one of these boxes. It might give us language for discussing the appropriate level of abstraction for each element we need. Of course since this is the first time I've heard of it, it may take longer to explain the framework than it is worth. I'll keep you posted if it keeps looking good. Brenda |
|
From: Eleanor S. <el...@dy...> - 2010-05-09 00:11:39
|
On Sat, May 08, 2010 at 04:38:55PM -0700, Brenda Larcom wrote: > On May 8, 2010, at 10:14 AM, Eleanor Saitta wrote: > > For the most part I agree with you, but I think there's another level of > > question, which is basically "how does the mindset of this tool think about > > <topic>?" There are times when the UI itself isn't that hard to figure out, > > but what I'm missing is the worldview of the designers, and once I understand > > that, I can figure out the UI bits pretty quickly. I.e., straight forward UI > > with behaviour that deviates siginificantly from my mental model. > > Can you give some examples of <topic> for Trike? Hrm. For us, the big example is, well, how do we think about threat modeling, but a better-mapped example might be version control -- that's the kind of thing that there are a lot of different mental models for and where once you know the model, the UI can, or at least should, get a lot easier, even if you still need lower-level help. > > ... I think my take away was > > that while it was a really interesting prototype, I couldn't imagine trying to > > actually suggest that as a real final implementation. (I'd assumed that it > > was only ever intended to be a prototype, or I would have mentioned that > > explicitly.) > > Well, more of a stopgap implementation so I could get some modeling done > before implementing the full Squeak version. I agree that it was never > intended as a final implementation, though I was surprised how much I was > able to make work. I do think we should release it (calling it a prototype > even though that's not quite true), because it is significantly more > functional than our previous prototype. Of course; not really worried abobut that, more just saying I'm with you on moving back to real code. > >> - A big question mark button, really prominently in the upper right corner > >> the startup screen > >> - A smaller question mark button in the upper right corner of every screen > >> - Route all the question mark buttons to the help index, which contains the > >> above 3 topics plus a basic Squeak UI manipulation reference, and darn well > >> better be searchable > >> - Have the Squeak UI reference explain the halos > >> - Put "What's this?" in the halos as a question mark > > > > While I do like the halos, when I'm looking for UI help, I really don't want > > to have to figure out a custom UI widget -- they're really non-intuitive when > > you haven't spent a fair bit of time with squeak. > > Hmm. I'm not sure I'm all the way convinced, but that's a reasonable line > of argument. My lack of convincement ;) is because I'm not sure we will be > able to implement everything we would want in the diagramming sections > (e.g. changing colors, grouping objects) without the halos. In short, I > think users might need to learn to use them to use all of Trike. If this > were the case, taking them to the help section to learn it ASAP, and having > them practice by getting help, could make some sense. If we're using the halos elsewhere, then I definitely agree that that makes sense, but only then. > I can't find any kind of help cursor type thing anywhere in Word (for Mac).. > Where do I find it? When I click on their question mark it just takes me to > their online manual. I want us to have something more, to allow people to > find out about anything they can see on the screen. From your brief > description I'm imagining that you click a button, the cursor turns into a > question mark, and anything you hover over? click on? displays balloon help > describing what it is? This is more modal than the halos are, imho. I can > see the argument that halos are modal, because when they are up and you > click on something else it makes the halos go away rather than doing what it > usually does, but it feels like "it didn't work" vs. "it was in some weird > state and it worked differently". I'm pretty sure we could change that > behavior if we wanted (i.e. make other clicks work even when the halos are > up), although I'm not sure we'd like the results. You're right on the description; maybe that's an office 2003 only thing? Not sure. The sense of modal that I meant (I think) was that you have to invoke something modal to *find* the help function; I'm ok with help being modal, I think, if the way to invoke it is visible. As far as making the halos more intuitive, would it be possible to draw something translucent and grey over everything but the halo and the actual widget they're referring to when they come up? How hard would that be? > Hmm.. I was hoping to use the ? icon to help alleviate our space crunch > problems with the tab names. If it has to be written out, I'd rather say > Help vs. Documentation... > > Are you saying we should use the Help tab as the startup screen? I think I > like continuing to use the About tab as the startup screen better.. I like > new users, but I don't want to show existing users the Help tab every time > they start up. Hrm. No, I didn't mean having people start on the help tab. Given that, and thinking about the UI more, a Help or a ? tab probably does make more sense. The "white ? on a blue background" style icon for help seems to be fairly universal these days; that might work ok as an icon. > The value I see is: "You can investigate and manipulate anything you see on > the screen in exactly the same way." The realization that this extends to, > e.g. menu items, icons, and other UI elements seems vitally important to me. > I can buy in, though: maybe the only reason this seems important is that I > want to hack the tool itself. We could set it up so that when the > "developer" setting or whatever we called it is checked, there are a few > more help topics in the help TOC, and a few deeper entries in What's this?. Yes. I think that should be a developer-only thing. I think if people have to understand that much depth about the UI, we've done something wrong. I think this may be a case of being a little too far into the system to see the beginner mindset, where once you're an experienced squeaker, that seems fundamental, but for an outsider, it's really not. > Over the long term, it would save us some UI dev time, too. Plus we already > need a facility for showing 2 tabs in parallel, so it could use that. The > UI driving part will still be some work. We can totally start with just a script-like thing in a parallel tab, and think about UI driving later.. Being able to have two tabs up at once in general would be really nice in many casaes, I think. > It really is. I mean, think of all those tentacles! You could point to > more than one part of the UI at once! And it would be so cute! And since > we are years ahead of schedule, have hundreds of developers on staff, are > being paid millions to do this, and have no day jobs.... Right. Check. No > animated octopus. That would really be kind of cool.... I can just see it riding the tricycle onto the screen, leaving it parked in front of something important that you were trying to read, and then pointing at stuff excitedly and chittering while it leaves tentacle marks all over your screen. :-) /Ella -- All models are wrong; some are useful. -- George E. P. Box |
|
From: Brenda L. <asp...@hh...> - 2010-05-08 23:52:42
|
On May 8, 2010, at 10:14 AM, Eleanor Saitta wrote: > On Sat, May 08, 2010 at 01:42:20AM -0700, Brenda Larcom wrote: > >> ... I have come to some conclusions about what new users >> of something very different from what they are used to want to see in >> documentation: >> >> - What's this? (What am I looking at and what does it do?) >> - How do I ...? (How do I accomplish my immediate task?) >> - What does ... mean? (What does this new concept I ran into in the other >> documentation actually mean?) >> >> They don't want to hear word one about how it is designed behind the scenes, >> or fluffy marketing speak about how it will change their lives. > > For the most part I agree with you, but I think there's another level of > question, which is basically "how does the mindset of this tool think about > <topic>?" There are times when the UI itself isn't that hard to figure out, > but what I'm missing is the worldview of the designers, and once I understand > that, I can figure out the UI bits pretty quickly. I.e., straight forward UI > with behaviour that deviates siginificantly from my mental model. Can you give some examples of <topic> for Trike? >> Based on my use so far, I think the spreadsheet has some pretty serious >> usability problems, ... > ... I think my take away was > that while it was a really interesting prototype, I couldn't imagine trying to > actually suggest that as a real final implementation. (I'd assumed that it > was only ever intended to be a prototype, or I would have mentioned that > explicitly.) Well, more of a stopgap implementation so I could get some modeling done before implementing the full Squeak version. I agree that it was never intended as a final implementation, though I was surprised how much I was able to make work. I do think we should release it (calling it a prototype even though that's not quite true), because it is significantly more functional than our previous prototype. >> I'd like to see us put together a full suite of embedded docs for the Squeak >> version. I'm thinking this: > > Yes --- the essay that went with the last version wasn't ever really intended > to be docs for the actual tool, but to be some other thing, and I think it was > useful as such, but it didn't really help too much for people who didn't get > how to use the tool. I.e. everyone.... :( >> - A big question mark button, really prominently in the upper right corner >> the startup screen >> - A smaller question mark button in the upper right corner of every screen >> - Route all the question mark buttons to the help index, which contains the >> above 3 topics plus a basic Squeak UI manipulation reference, and darn well >> better be searchable >> - Have the Squeak UI reference explain the halos >> - Put "What's this?" in the halos as a question mark > > While I do like the halos, when I'm looking for UI help, I really don't want > to have to figure out a custom UI widget -- they're really non-intuitive when > you haven't spent a fair bit of time with squeak. Hmm. I'm not sure I'm all the way convinced, but that's a reasonable line of argument. My lack of convincement ;) is because I'm not sure we will be able to implement everything we would want in the diagramming sections (e.g. changing colors, grouping objects) without the halos. In short, I think users might need to learn to use them to use all of Trike. If this were the case, taking them to the help section to learn it ASAP, and having them practice by getting help, could make some sense. I guess I should implement a diagramming section & see if we can make it work with no halos. > I'd recommend that we have > the clickable question mark do the "help cursor" type thing -- office does it > this way -- so people don't have to invoke a modal UI to find help. /me investigates Office's help system I can't find any kind of help cursor type thing anywhere in Word (for Mac).. Where do I find it? When I click on their question mark it just takes me to their online manual. I want us to have something more, to allow people to find out about anything they can see on the screen. From your brief description I'm imagining that you click a button, the cursor turns into a question mark, and anything you hover over? click on? displays balloon help describing what it is? This is more modal than the halos are, imho. I can see the argument that halos are modal, because when they are up and you click on something else it makes the halos go away rather than doing what it usually does, but it feels like "it didn't work" vs. "it was in some weird state and it worked differently". I'm pretty sure we could change that behavior if we wanted (i.e. make other clicks work even when the halos are up), although I'm not sure we'd like the results. If we wanted to be non-modal, we'd have them hold down F1 continuously while hovering over/selecting the thing they want to investigate. But... - I'm pretty sure my keyboard can't do that, and there will be trouble with on-screen keyboards, too. - I'm not sure there are enough actual modifier keys around for us to use one up for help. - It will make reading "What's this?" style help physically tiring. - It will limit the amount we can say about whatever they are looking at. - I don't see how they can select the scope they want to hear about for "What's this?". Well, I do, but the only thing I can think of would basically be a really-annoying-to-use special purpose version of the halos, and it would prevent people from using Trike with just a keyboard or just a mouse. > The basic > help menu can be on the startup screen and possible a "Documentation" tab. Hmm.. I was hoping to use the ? icon to help alleviate our space crunch problems with the tab names. If it has to be written out, I'd rather say Help vs. Documentation... Are you saying we should use the Help tab as the startup screen? I think I like continuing to use the About tab as the startup screen better.. I like new users, but I don't want to show existing users the Help tab every time they start up. > Do we need to tell people about morphs? I.e., when do we get too low level? > We can assume, I think, that everyone who's using the tool gets that UIs are > composed of discrete elements, but I don't think there's much value to telling > anyone who's not hacking on the tool what they are, and I'd maintain that > programmer docs should be seperate from user docs. The value I see is: "You can investigate and manipulate anything you see on the screen in exactly the same way." The realization that this extends to, e.g. menu items, icons, and other UI elements seems vitally important to me. I can buy in, though: maybe the only reason this seems important is that I want to hack the tool itself. We could set it up so that when the "developer" setting or whatever we called it is checked, there are a few more help topics in the help TOC, and a few deeper entries in What's this?. > I like the idea of having a workflow -- the benefits of a wizard, but without > a seperate UI, so people who go through the workflow learn the interface on > their own. In general, being able to have help visible along side what you're > working on is a very good thing; not having that is a real pain when you're > trying to learn a complex UI. Over the long term, it would save us some UI dev time, too. Plus we already need a facility for showing 2 tabs in parallel, so it could use that. The UI driving part will still be some work. > I wouldn't go any further along the assistant > route than that, as tempting as the idea of an animated octopus pointing > things out is. It really is. I mean, think of all those tentacles! You could point to more than one part of the UI at once! And it would be so cute! And since we are years ahead of schedule, have hundreds of developers on staff, are being paid millions to do this, and have no day jobs.... Right. Check. No animated octopus. Remembering the paperclip, Brenda |
|
From: Eleanor S. <el...@dy...> - 2010-05-08 17:14:45
|
On Sat, May 08, 2010 at 01:42:20AM -0700, Brenda Larcom wrote: > I was trying to learn to use Eclipse. I have an unrelated project and > thought it was about time. In wading through their documentation, which is > very... architectural, I have come to some conclusions about what new users > of something very different from what they are used to want to see in > documentation: > > - What's this? (What am I looking at and what does it do?) > - How do I ...? (How do I accomplish my immediate task?) > - What does ... mean? (What does this new concept I ran into in the other > documentation actually mean?) > > They don't want to hear word one about how it is designed behind the scenes, > or fluffy marketing speak about how it will change their lives. For the most part I agree with you, but I think there's another level of question, which is basically "how does the mindset of this tool think about <topic>?" There are times when the UI itself isn't that hard to figure out, but what I'm missing is the worldview of the designers, and once I understand that, I can figure out the UI bits pretty quickly. I.e., straight forward UI with behaviour that deviates siginificantly from my mental model. > Based on my use so far, I think the spreadsheet has some pretty serious > usability problems, partly because it is so hard to put real help, workflow > automation, or explanatory text into an Excel file using only formulas, > partly because apparently there are serious portability issues between > versions of Excel (not to mention OpenOffice), and partly because the > automation just can't go far enough. So, this is a fine stopgap & I'll > probably issue at least one more version, which we can then release, but for > the most part, I'm back to thinking about the Squeak version. Yeah; I haven't had time to test this further, in part because my netbook is MIA, coming back from Cleveland, I just sort of assumed that the older mac I'm using for the moment wouldn't be able to do anything intelligent with it. I did spend some time playing with it, thought, and I think my take away was that while it was a really interesting prototype, I couldn't imagine trying to actually suggest that as a real final implementation. (I'd assumed that it was only ever intended to be a prototype, or I would have mentioned that explicitly.) > I'd like to see us put together a full suite of embedded docs for the Squeak > version. I'm thinking this: Yes --- the essay that went with the last version wasn't ever really intended to be docs for the actual tool, but to be some other thing, and I think it was useful as such, but it didn't really help too much for people who didn't get how to use the tool. > - A big question mark button, really prominently in the upper right corner > the startup screen > - A smaller question mark button in the upper right corner of every screen > - Route all the question mark buttons to the help index, which contains the > above 3 topics plus a basic Squeak UI manipulation reference, and darn well > better be searchable > - Have the Squeak UI reference explain the halos > - Put "What's this?" in the halos as a question mark While I do like the halos, when I'm looking for UI help, I really don't want to have to figure out a custom UI widget -- they're really non-intuitive when you haven't spent a fair bit of time with squeak. I'd recommend that we have the clickable question mark do the "help cursor" type thing -- office does it this way -- so people don't have to invoke a modal UI to find help. The basic help menu can be on the startup screen and possible a "Documentation" tab. > - "What's this?" should have multiple answers. E.g. if you get halos on a > data store in a DFD, it might say all of: > - The engineering department's main file share. (This should come from > their description.) > - An NFS server. (This should come from their technology annotations.) > - A data store. > - A DFD element. > - A drawing element. > - A morph. > Each answer should be clickable to get the user to more information about > that kind of thing. Do we need to tell people about morphs? I.e., when do we get too low level? We can assume, I think, that everyone who's using the tool gets that UIs are composed of discrete elements, but I don't think there's much value to telling anyone who's not hacking on the tool what they are, and I'd maintain that programmer docs should be seperate from user docs. > - I hesitate to suggest it, but maybe some kind of assistant pane? > - The "How do I ...?" documents should have embedded "Take me there" > buttons; when you press them, it should move the help onto the assistant > and take you to that part of the UI, highlighting the buttons to push > along the way. > - We could implement work flows for different use cases this way. > - If you're not doing a work flow, it could describe tasks you can do on > this tab, and tips for doing them. Maybe. I like the idea of having a workflow -- the benefits of a wizard, but without a seperate UI, so people who go through the workflow learn the interface on their own. In general, being able to have help visible along side what you're working on is a very good thing; not having that is a real pain when you're trying to learn a complex UI. I wouldn't go any further along the assistant route than that, as tempting as the idea of an animated octopus pointing things out is. /Ella -- There are things to be said for living with your skeletons in the daylight. |
|
From: Brenda L. <asp...@hh...> - 2010-05-08 08:42:35
|
I was trying to learn to use Eclipse. I have an unrelated project and thought it was about time. In wading through their documentation, which is very... architectural, I have come to some conclusions about what new users of something very different from what they are used to want to see in documentation:
- What's this? (What am I looking at and what does it do?)
- How do I ...? (How do I accomplish my immediate task?)
- What does ... mean? (What does this new concept I ran into in the other documentation actually mean?)
They don't want to hear word one about how it is designed behind the scenes, or fluffy marketing speak about how it will change their lives.
Based on my use so far, I think the spreadsheet has some pretty serious usability problems, partly because it is so hard to put real help, workflow automation, or explanatory text into an Excel file using only formulas, partly because apparently there are serious portability issues between versions of Excel (not to mention OpenOffice), and partly because the automation just can't go far enough. So, this is a fine stopgap & I'll probably issue at least one more version, which we can then release, but for the most part, I'm back to thinking about the Squeak version.
I'd like to see us put together a full suite of embedded docs for the Squeak version. I'm thinking this:
- A big question mark button, really prominently in the upper right corner the startup screen
- A smaller question mark button in the upper right corner of every screen
- Route all the question mark buttons to the help index, which contains the above 3 topics plus a basic Squeak UI manipulation reference, and darn well better be searchable
- Have the Squeak UI reference explain the halos
- Put "What's this?" in the halos as a question mark
- "What's this?" should have multiple answers. E.g. if you get halos on a data store in a DFD, it might say all of:
- The engineering department's main file share. (This should come from their description.)
- An NFS server. (This should come from their technology annotations.)
- A data store.
- A DFD element.
- A drawing element.
- A morph.
Each answer should be clickable to get the user to more information about that kind of thing.
- I hesitate to suggest it, but maybe some kind of assistant pane?
- The "How do I ...?" documents should have embedded "Take me there" buttons; when you press them, it should move the help onto the assistant and take you to that part of the UI, highlighting the buttons to push along the way.
- We could implement work flows for different use cases this way.
- If you're not doing a work flow, it could describe tasks you can do on this tab, and tips for doing them. Maybe.
Thoughts?
--B
|
1 message has been excluded from this view by a project administrator.