You could just give plugins ratings on the "usual" plugin spots... like, TiddlySpot etc.
These ratings could have multiple sections... Ease of use : Gold Security : N/A So community members / users / plugin "spots" should review all plugins on their site for security concerns. For instance the Math plugin (can't recall which one) which calls a website to create a PNG or GIF of the mathematical equation should not get Gold in security, because it's accessing another website. I guess that's my 2c... Regards, -Reenen On Thu, Apr 9, 2009 at 5:31 PM, Mark S. <[email protected]> wrote: > > If automation alone could solve the viral code problem, then certainly > the world's largest software company would have stamped it out by now. > > Certification and authentication would make the code bulkier, the > import process more complicated, and probably not add much protection. > Unless, of course, TW authors are more rigorous about the > certification process than are other types of code authors. Or if the > certification process is a lot simpler. > > Before getting into TW I reviewed dozens of information manager > programs. I'm guessing there were at least a half dozen installs where > a little box came up warning me that there was no certification for > the program about to be installed. But what could I do? Abandon the > installation? I had already scanned for viruses, of course. The > authors simply hadn't taken the time to go through the MS > certification process. Or maybe it takes money. Don't know. > > But if authors spending hours full blown distributions weren't willing > or able to include certifications, what hope is there that script > writers, with shorter time horizons, will be willing? > > Users seeing certification warnings will eventually learn to ignore > them if it appears to be the norm. > > A different solution might be to have a large clearing house for > vetted code, something along the lines of the TiddlyVault (which seems > to be a bit outdated now). Only it would have the actual code so that > viral code couldn't be swapped for good code. Why bother with hash > storage and SHA signatures when the code itself doesn't take up a > whole lot of space? I'm guessing that all the code on TiddlyVault, if > downloaded, would fit on a single CD. > > Code could be marked as having been reviewed by known reviewers, > something like the way Wikipedia works. With star security ratings. > The higher the rating, the presumably the safer the code. Established > authors would be able to post automatically with high rankings. TW'ers > could be encouraged to pull mainly from this source, but of course > could go elsewhere under advisement. > > -- Mark > > On Apr 9, 6:01 am, Martin Budden <[email protected]> wrote: >> Jel, >> >> I agree that TiddlyWiki should have some security awareness. >> >> We've talked a bit about adding the ability to authenticate plugins >> before they are loaded. The TW core already contains code to generate >> SHA-1 hashes, so it would be a matter of generating the SHA-1 hash of >> a plugin and comparing it with a centrally held value, held for >> example on TiddlyVault as you suggest. >> >> The trouble then is who assesses the plugins. Self-authentication is >> no protection against a malicious plugin writer. We could have some >> kind of community assessment, though. >> >> Martin >> >> 2009/4/8 Jel <[email protected]>: >> >> >> >> > None in particular. However, I note that we have - since you invited >> > me to put this up as a placeholder, moreover - <a href="http:// >> > groups.google.com/group/TiddlyWiki/browse_thread/thread/ >> > 8bdc3f1dca95c83b">a case of an infection</a> reported on the User >> > forum which is a case in point - the poster was in no way responsible, >> > but others could have been caught. >> > My general point is that ALL applications really should be, and should >> > be seen to be, security-aware - there will be no thanks if we start >> > getting on installation blacklists with MS and the like because we've >> > been somewhat careless, Windows 7 and upwards can be expected to >> > become increasingly alert to problems, and since there's some redesign >> > thinking going on, it's probably not a bad time to consider if any >> > precautions are needed to authenticate code in the Plugin upload >> > routines, for example. Not all users are programmers, and so not all >> > can be expected to be able to intercept a call to some nasty assembler >> > code hooked in to an otherwise anodyne href call to such a site, for >> > instance. >> > What might be sensible as a first-level protection would be to include >> > some form of CTC assessment of authenticated code in the field >> > specification for each tiddler, and to run it (offering an alert if >> > missing or not authenticated) before loading code tiddlers: it might >> > be an interesting question whether to include an assessment routine in >> > the standard package, for instance, or whether to have an independant >> > assessor - TiddlyVault or the like springs to mind, although I haven't >> > had the courtesy to ask them, for which I apologise. Others will >> > certainly be wiser in the subject than yours truly, however. >> >> > > > -- o__ ,_.>/ _ (_)_\(_)_______ ...speed is good _______________ I believe five out of four people have a problem with fractions. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
