IRC Log Viewer » #firebreath » 2010-12-17

IRC Nick Time (GMT-7) Message
DFUN 08:12 uh... 5 minutes before vacation: DefaultBrowserStreamHandler::getStream() returns 0 and now I don't know how to cancel a download. I'm pretty sure it worked with FB 1.3.1.
I'm now using 1.3.2
neilg_, I guess that's still "your" topic
for this year I will just leave it like that. See you again in January!
neilg_ 08:12 Oh. Um...
:)
nitrogenycs 08:12 lol
taxilian 10:12 morning all
I wonder how long it'll take before firebreath.org is the first google result for a search for "firebreath". currently the google code page is...
neilg_ 10:12 Morning! Well, morning for you anyway. :) The more people who link to firebreath.org then the faster it'll make #1!
taxilian 10:12 yeah; I went through and changed all the links I could modify on stackoverflow to point to firebreath.org instead of code.google.com for just that reason
taxilian 13:12 quiet around here today
taxilian 14:12 hey, ya'll… I'm adding support to JSAPIAuto for dynamic attributes; that is, a FB::VariantMap that you can set attributes on that will be used as properties if no other property is there. Thing is, we may need the ability to have it automatically set an attribute the way it would if it were a normal HTML element, but I'm not sure if that should be enabled by default. thoughts?
kylehuff 14:12 it isn't empty - I just don't really know what the hell you are talking about.. =c )
taxilian 14:12 lol
so you could do something like plugin().someRandomProperty = "asdf"
and if m_allowDynamicAttributes is true it will save that value
and plugin().someRandomProperty will return "asdf"
the main advantage to this right now would be better integration with jQuery and other similar things that enjoy setting random attributes on elements they touch
kylehuff 14:12 yeah, I can think of a few cases where that would have been handy to have actually
taxilian 14:12 so the question is, should it be enabled by default?
support will be, so there'll be a FB::VariantMap m_attributes member that will be used by default as read-write attributes if you want to set them, and I might even add something so you can mark certain ones read-only, but the question is whether or not you should be able to set new values from javascript by default
kylehuff 14:12 in my opinion, that kind of behavior is in form with the html/javascript side, and that makes sense - you can specify arbitrary properties to objects; when you think about it on the C/C++ side though, it is against the grain.
being as it's usage is from the html/javascript side anyway, I can't think of a reason not to enable it by default.
taxilian 14:12 kalev, nirvdrum, nitrogenycs, thoughts?
nitrogenycs 14:12 I like it. The plugin is just an element in the dom, so it ought to behave like it
taxilian 14:12 ok; 3 votes for, none (yet) against; you can always turn it off yourself
nitrogenycs 14:12 are there any reasons against it? security or something else?
taxilian 14:12 the only one I can think of is that it does make it slightly more likely that you could make a mistake and not notice (i.e. set an attribute or property with a typo and it doesn't throw an error anymore)
nitrogenycs 14:12 ahh ok. I guess people using javascript are used to that :)
taxilian 14:12 generally we are, yes =]
however, it seems like I'm more in the minority as a plugin developer who has a lot of experience doing weird crap in javascript :-P
ChanmanX 14:12 Hi guys, I have a question. How would users install a Firebreath plugin if they are running Safari on OS X? Do they really have to download it and copy it to $HOME/Library/Internet Plugins?
taxilian 14:12 well, if it were me, I'd have them download a .pkg or .dmg with a script / install program to copy it to $HOME/Library/Internet Plugins
but that's basically how the installation works
some even use a java downloader/installer
ChanmanX 14:12 At that point, does Safari have to be reloaded?
taxilian 14:12 not usually
one thing to know, however
is that if you replace the plugin with a newer version, Safari won't detect it unless you put the new one in with a different name and delete the old one
if you just replace it Safari (and Firefox as well, I think) won't detect it
I usually just cycle with a ~ at the end of the plugin name
ChanmanX 14:12 Yeah, the same problem occurs with the CLSIDs in MSIE.
taxilian 14:12 i.e.. FBTestPlugin.plugin, then FBTestPlugin~.plugin
not at all
ChanmanX 14:12 I had a very hard time convincing IE to re-download the .cab. In the end I just changed the class ID.
taxilian 14:12 MSIE will load a new plugin version if you install a new plugin as a different filename and register it with the same CLSID
well, I can't speak for downloading the cab
that's one reason that I don't like using cab files
ChanmanX 14:12 ah, different filename, that makes sense
taxilian 14:12 unreliable at times, weird sometimes
I just use an MSI
that way it's always the same
so the .cab might not work.. but if you register the new file, that works. I've done that
ChanmanX 14:12 Have you had people writing Firebreath plugins that were installed via XPI for Firefox?
taxilian 14:12 I believe so
I've done it with other plugins, before I created FireBreath; it definitely can be done
but it will only work on firefox
is this you? http://stackoverflow.com/questions/4468708/deployment-of-npapi-plugin-with-minimal-user-steps
ChanmanX 14:12 yes, that's me
sorry, I totally get you on the .msi thing, I know it's easy, but users are going to freak
taxilian 14:12 yeah, I really should put up a wiki page on firebreath.org on the subject
ChanmanX 14:12 they think they're "installing" something, even though technically, it's the same
with XPIs all you have to do is click allow/install now.. from a user's mental perspective, it's different
taxilian 14:12 there has been a lot of discussion on it on this channel
this is true; installing is the single worst problem faced by plugin devs
however, if you want to support multiple browsers, there simply aren't good options
ChanmanX 14:12 but you've done it before?
taxilian 14:12 MSI is the one that works everywhere; you can do that or you can do 3 different versions… and one of them will still be the MSI
it's been awhile and I can't give you an example, but it can be done, yes
we had problems with it, though
nitrogenycs 14:12 is there some wiki page for deployment and updating?
taxilian 15:12 not really =] the closest ones I think you've seen already. I linked both of them on the stackoverflow answer I referenced a minute ago
has anyone tried packaging an npapi plugin in a chrome extension so that it is useable as a plugin?
nitrogenycs 15:12 maybe we should setup pages for deployment and updating. There we can explain the different approaches and methods. Like msi, cab, doing it on mac. Installing per-user instead into program files so you can perform automatic updates and so on. What to put into your installer (e.g. regsvr32 etc)
I don't think you can talk everybody into the wix installer
ChanmanX 15:12 http://www.mail-archive.com/[email protected]/msg05365.html
taxilian 15:12 nitrogenycs: we definitely shoud. the problem is that usually on something like that, "we" means "taxilian" =] and I don't have time right now. If you want to start one, though, I'll try to add to it
ChanmanX 15:12 sounds like it can't be done for chrome
taxilian 15:12 yeah, that's how I read it as well
so for Chrome, Safari, and Opera your only option is an installer, which means EXE or MSI
of those, MSI is definitely the better option
nitrogenycs 15:12 I'll see if I can write something about the process I use. Then people can enhance it with more infos for their platform, those auto-install methods like cabs/xpi/etc. That's where the wiki might get useful
taxilian 15:12 absolutely
that would be great
ChanmanX 15:12 wait, MSI will work on Safari Mac OS X?
taxilian 15:12 ChanmanX: no, I'm referring to windows only
ChanmanX 15:12 so what solution is there for Mac?
script to copy I guess..
taxilian 15:12 on mac the best solution I've found is to use a java applet to download and install it
with a .dmg and an install script as a backup for those users too paranoid to click "trust" on the java applet
you have to sign the applet, though
ChanmanX 15:12 sort of a longshot here.. but do you have a link or URL for the example code?
not a problem signing
taxilian 15:12 not at the moment; I might be able to get Facebook to let me open theirs.
but no guarantees
nitrogenycs 15:12 I think it's better signing everything having to do with the plugin
taxilian 15:12 agreed
ChanmanX 15:12 might be useful. the whole thing on firebreath is awesome, it's just the deployment problem
nitrogenycs 15:12 something to put in the guide as well :)
ChanmanX 15:12 it's no good if users can't touch it
taxilian 15:12 ChanmanX: I wrote a paper pretty much summarizing the whole plugin mess; I'll send you a link when I find it (gimme a minute). I'm still looking for a place to publish it (in my "spare time") so please don't distribute it
here it is; you'll have to create an account on firebreath.org to get to it. http://www.firebreath.org/download/attachments/2162709/Web+Browser+Plugins+in+the+Age+of+Web+Applications.pdf
I gotta go grab some lunch; I'll be back in an hour or so
ChanmanX 15:12 sure, I won't distribute. thanks.
taxilian 15:12 no problem. I hope it helps.
be back later
nitrogenycs 15:12 I created a very rough skeleton for the install/update plugin stuff: http://www.firebreath.org/display/documentation/Deploying+and+updating+your+plugin . Feel free to correct and add more stuff in there.
taxilian 17:12 nitrogenycs: awesome. thanks
taxilian 17:12 nitrogenycs: I've updated it somewhat to clarify some things. I'll try to put more info up when I have more time. Thanks for creating this page; it'll be a great resources.
nitrogenycs 17:12 cool, thanks for the additions, looks already much better now :)
didn't know regsvr32 was bad practice
one thing I am curious about is whether it makes sense to install into the LocalLow folder. If you install any data files in there you need to sign them somehow. Otherwise other plugins could cause your plugin to do naughty things by manipulating the data.
Of course it's debatable whether you want to protect against that
taxilian 17:12 when it comes to plugins, anything other than an MSI is dangerous, but the main problem with regsvr32 is that it is really easy to change what DllRegisterServer does and forget that that affects what you have to do when you uninstall an old version of the plugin
it's much better to have all isntall stuff in one place; an MSI simplifies things by just recording what was done so that it can be undone
RE: LocalLow there are times when you have to use LocalLow; I usually install in Local, and then sometimes use LocalLow for temporary storage, etc
nitrogenycs 17:12 yeah. That's true.
yeah, I've also seen one plugin in the wild that installs into LocalLow
the Microsoft guidelines say anything that has low priviledges should not be trusted
taxilian 17:12 makes sense
nitrogenycs 17:12 so you can trust your own executable since it's signed
but nothing else from locallow really. That made me stay away from it
taxilian 17:12 makes sense. I wouldn't put trusted data there, but from within IE it's all you have access to
probably wouldn't hurt to clarify that in the docs somehow
nitrogenycs 17:12 otoh I made some tests with the different integrity levels. When I was in low integrity mode I could still read files from my own Documents folder. Which I considered a bit strange, while the plugin cannot damage my system that way it can surely steal lots of important data
yeah, I use the broker process to get medium rights whenever I need them
taxilian 17:12 yeah; the whole thing seems like it's not real well done; it's more of a faux security system
it looks secure, until you learn more about it and realize that it's really just a bunch of stuff that gets in your way and makes it hard to do anything useful, but still can be circumvented if someone is really determined to do mischief
nitrogenycs 17:12 yeah, that's what I was thinking too. If they wanted to sandbox it, they should have done it better imo. But if a plugin can't do anything in the end, it's also not useful anymore
yeah, exactly
taxilian 17:12 grr. this dynamic property thing is a beast; it won't allow anything to set properties that aren't "supported", but if I return true on a method name it will get the property instead of the method, causing an exception
taxilian 21:12 anyone around? I need someone to bounce ideas off of =] kalev? kylehuff?
kylehuff 21:12 yeah, I'm around, but I'm also asquare..
taxilian 21:12 that's close enough
have you used the FireEvent feature of JSAPI?
kylehuff 21:12 Yes
I think, let me make sure
taxilian 21:12 so I've been looking into what would make it possible to use jquery with FireBreath plugins
since jquery is such a popular js framework
and because I'm lazy at heart and don't want to maintain my own stuff
kylehuff 21:12 lol
(yes, I am using)
taxilian 21:12 I added the dynamic properties thing, which makes it so that jquery can set its magic stuff
and that's all working great
the problem is that DOM events work fundamentally different from FireBreath events
they all pass an event object which has the properties and such that are wanted
kylehuff 22:12 right
taxilian 22:12 so I'm thinking it might be a good to make FireBreath conform to that standard...
http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030331/ecma-script-binding.html
this of course would either require us to have two options for firing events or add a breaking change with far-reaching consequences (anyone currently using events, their events will stop working as expected)
what do you think?
kylehuff 22:12 well, I am using an event in 2 places of the same method - so for me a breaking change doesn't hurt my feelings. But, I don't know exactly what would be gained with the change.
taxilian 22:12 the main thing would be that you could use existing javascript frameworks and their event handling methods
for attaching events and so forth
and of course making FB plugins look more like normal DOM elements
kylehuff 22:12 so, other than the breaking change, what is negative about the move?
taxilian 22:12 that's really it, I think
shouldn't have much overhead; basically the event object would just create a map with the right members
so it would be different, but more like what is expected in javascript
kylehuff 22:12 well, in the long run it could make the plugins more flexible, which helps with adoption and usability. The alternative, staying the way it is only helps those who are already using events.
(which is probably a small number, at this point)
taxilian 22:12 we would hope that that is a smaller number than what will be using it, anyway =]
kylehuff 22:12 right
taxilian 22:12 I've said it before… I would give a lot to know how many are using it =]
enough come through here to guess at least several dozen
whether they are all still using it or not, I don't know
kylehuff 22:12 yeah - I am lucky because I can embed google analytics into my chrome extensions
taxilian 22:12 hehe. yeah, that's pretty cool
so you're using a firebreath plugin inside your chrome extension, right?
kylehuff 22:12 yeah
I will be doing the same with a fire extension in a few months (same plugin)
taxilian 22:12 awesome
so with that extension, is there some way to make it so that the npapi plugin included can be used in the page?
like you can with firefox extensions?
kylehuff 22:12 Yes, you can specify in the manifest to make the plugin "public"
taxilian 22:12 really? interesting. Chanman was trying to figure out how to do that
very interesting
if you were to have a chance to write up some quick details on that, it would be awesome to have the general procedure on http://www.firebreath.org/display/documentation/Deploying+and+updating+your+plugin
kylehuff 22:12 I am using it as a "private" plugin though, so only the extension pages can access the plugin
taxilian 22:12 right
I'd really love to see a wiki page on how to do that too =] but one thing at a time
the more ways people see that FireBreath can be used, the more it will get used
kylehuff 22:12 sure, I can add how to do it. it is really simple
I can also flesh out the "Linux" section
taxilian 22:12 that would be awesome
I think I've told you before, but I really do appreciate your willingness to help
kylehuff 22:12 I *hope* to be submitting this extension to the google extension gallery
taxilian 22:12 it's relatively rare to have people who not only are willing to hang around and answer questions but also actually do something now and again =]
though the percentage of those people to other people is much higher in this room than is the norm, from my experience
kylehuff 22:12 no problem, FB is going to save me billions of hours....
taxilian 22:12 it better… considering the billions of hours I've put into it =]
kylehuff 22:12 lol
well, I just hope this stupid extension (or even an off-shoot of it) gets used.
taxilian 22:12 hmm. I think instead of forcing firebreath users to do things "DOM-compatible", for now I will just make it really easy to do it "right"
what does it do?
I'm sure you've said, but my memory for details not related to FireBreath is sketchy sometimes =]
kylehuff 22:12 no, I don't think I have said before.. it does GPG/PGP authentication
taxilian 22:12 ahh.. you know, you're one of, like, 4 people I know of doing something similar
you seem to be further along than the others, though =]
what do you use for your keystore?
and is this backed by a company?
kylehuff 22:12 the keystore is your local keyring
and no, not technically. my company isn't involved.
taxilian 22:12 so is this a project you hope to get paid for or just one you're doing for fun?
kylehuff 22:12 i'm trying to save the damn planet! username+password is stupid
taxilian 22:12 LOL
agreed =]
you should totally make a confluence plugin that uses it when you get it working; then we could use it on the firebreath page for wiki logins
kylehuff 22:12 this process (called gpgauth) is really really simple; you signup for service from, lets say, facebook, and you give them your public key, the next time you go there, facebook.com encrypts some data to your key and hands it to you; if you can decrypt it - you win.
taxilian 22:12 I like winning
kylehuff 22:12 the side-benefit is, you can also have the facebook public key, and make them do the same damn test
encrypt some junk to their key; if they can return it, they win
taxilian 22:12 sounds like a cool idea
kylehuff 22:12 anyway, years ago I wrote up a really horrible extension module that was included in FireGPG - I was hoping to just spark the idea (I am not a programmer)
nobody really cared to take off with it; so I am making into a better product - something actually usable.
taxilian 22:12 cool
kylehuff 22:12 and I am, I hope, about 2 days from submitting it into the google extension gallery
taxilian 22:12 awesome =]
brb
oh, good, n/m… I kicked my UPS and I thought my imac was about to shut off =]
kylehuff 22:12 opps..
anyway, this is how the plugin fits into the mix: https://github.com/kylehuff/gpgauth/raw/master/gpgauth-client-process.pdf
taxilian 22:12 Open source? cool
kylehuff 22:12 yeah
taxilian 22:12 it would be really cool if you'd consider putting a link to this on the firebreath website as an example
not an official example
just a "who is using firebreath" example that people can look at to see things that work
just a thought =] it's up to you
kylehuff 22:12 sure, once I submit I this extension I need to update the website (it still references the old process which used just events) - then we can add a link to the website
taxilian 22:12 awesome
you're using dev, right?
kylehuff 22:12 yeah
taxilian 22:12 cool. maybe you can help me test the new event model =] I'm just about done, I think
it still amazes me how easy some things are… =]
kylehuff 22:12 I wasn't, but I moved over to dev because 1.) I wanted to drop gtk-dev linking, and 2.) I am using the plugin as basically just an API to gpg, so nothing I am using is really unstable (even under dev)
taxilian 22:12 though I have an advantage over most people; if I can't do something I just add the feature so that I can
not much of dev is actually unstable
only things that I'm still changing, generally
kylehuff 22:12 anyway, I can test event stuff, I am using an event to notify my plugin about the status of a thread and it is pretty easy to test
taxilian 22:12 cool
kylehuff 22:12 *notify my extension
taxilian 22:12 I'm really bad at avoiding scope creep sometimes =]
kylehuff 22:12 =c )
taxilian 22:12 so I have the event thing more or less working… but I need to be able to include a javascript Date object
well, that's not really that hard… except that I need some sort of data structure
so I'm trying to figure out how much of boost date_time I can use before I have to link in the libraries =]
I think I'm just obsessed with being able to tell people "oh, yeah, that's easy in FireBreath"
kylehuff 22:12 well, it's entirely selfish, but I love it when you say that.. lol
taxilian 22:12 hehe. it's just… fun. =]
I'm actually adding some pretty significantish features to JSAPI this time around… that's something that hasn't been done in a long time
there have been no major improvements to JSAPI itself since we started, really
kylehuff 22:12 that is pretty much what I say every time someone cries that the can't remember one their billion passwords "oh, yeah, you wouldn't have that problem with gpgauth.."
taxilian 22:12 hehe
kylehuff 22:12 then I am reminded that it only really exists conceptually
taxilian 22:12 of course, if someone gets access to your cert somehow, you're almost more screwed
however, I agree that it's still generally better =]
easier to change everywhere, for one thing
kylehuff 22:12 except, your private key is encrypted with your passphrase, being as it is the only passphrase you ever need to remember, you can make it very strong
taxilian 22:12 true
kylehuff 22:12 and, you can always revoke your key
I need to find a license compatible with libgpg, so I can statically link it. that would make life for windows users easier.
taxilian 23:12 libgpg is… gpl?
kylehuff 23:12 gnu
not sure which version
looks like v2
taxilian 23:12 hmm. FireBreath is dual licensed to LGPL but I guess that's still not compatible
and I'm afraid I'm just not willing to release firebreath under the GPL. I more or less hate the GPL and other viral licenses
kylehuff 23:12 yeah, I don't really like other people dictating under what license I can release my code
I would like to include the libraries, but not if forces a license that could interfere with being used with other encryption backends
taxilian 23:12 if FireBreath were gpl I seriously doubt it would have even half the userbase it does
kylehuff 23:12 yeah. I guess the "product" or code I am releasing is nothing special, it is the protocol that I don't want tied to anything restrictive. anybody could replace what I have done (and probably should, as stated before, I'm not a programmer). in fact, I think this should be integrated into the browser itself (ala SSL)
you are in a different boat, because your code is designed to create derivative works.
taxilian 23:12 yeah
however, it's something I like doing a lot better; I've found I have a talent for creating reusable code. Sometimes it gets me in trouble when I don't really need something reusable =]
brb
kylehuff 23:12 sometimes I wish I had that problem.. most the time my code isn't reusable, because it has to be usable in the first place..
taxilian 23:12 well, I haven't looked real close at your code, but what I saw didn't look bad
kylehuff 23:12 it is currently worse than it will be (thankfully) - the documentation for libgpgme is old and scary, so I had all of the key operations in separate source files. now that I have it stable on linux, mac and windows - I can put it directly into the plugin API .ccp file do less passing around.
taxilian 23:12 always fun
kylehuff 23:12 I had anticipated doing the whole cross-platform NPAPI stuff with even more pain and suffering; but thanks to FB, I'm that part was really really easy (for me). So making the key stuff standalone was really a waste of time.
taxilian 23:12 hehe. how you feel about the username/password thing is kinda how I've always felt about plugins; it's just ridiculous that someone would have to know that much and jump through so many hoops
I could write a *long* book about how to write plugins from scratch, but you shouldn't even need to know all of that
the downside, of course, is that this way I'm the only one who does… if I ever can't keep up the project, not sure what'll happen with it
kylehuff 23:12 well, at that point your book would become a best seller
=c )