Yep, it's a local HTTP server by default. It's also possible to expose it via reverse proxy, and you can set basic auth password in the extension's settings.
What do you mean by slurping here? Security-wise, a random website shouldn't be able to query a localhost because of CORS policies.
Unfortunately, CORS isn't a magic bullet. Suppose a site named evil.example adds a script tag pointing to http://localhost:1234/promnesia.js and a victim loads evil.example. If your JS updates a DOM element with info from the database, evil.example's JS can read that DOM element and report it back to the server, without violating CORS.
Ah I see, thanks! Good point, and I guess basic auth would protect against such sort of attack.
So it seems it makes sense to use a token even if it's running as localhost, I could add an option, so it doesn't require setting up a separate proxy.
Either way, I hope I've been fairly reasonable about security so far, but I've mostly been concentrating on the 'plugging in the data' bit, so it's possible I've overlooked something (also I'm not a security specialist!). There is an open issue in case people have any specific concerns or spot something, happy to receive feedback! https://github.com/karlicoss/promnesia/issues/14
I think it's becoming clear that the whole 'local web server to do system things for a browser extension' approach is probably too fraught and should be abandoned for better IPC mechanism that browsers support. I don't think this is some 'drop everything and rewrite stuff' thing but it's worth reading up on and planning for.
Yeah, possibly. Chrome actually has something called "native messaging" https://developer.chrome.com/apps/nativeMessaging which seems like a potentially more secure (and faster?) alternative, but I haven't had time to play with it yet.
Yep, that's one of the things I had in mind when mumbling about 'better IPC'. Safari already only supports that type of model. I think the day is not far when automated scans/app stores/etc start flagging the local http server thing as high risk/potential malware vector. It's an architectural dead-end.
On the other hand, some of the other stuff may not be fully baked:
To follow up: the solution is that the localhost server needs to make sure each API call is authorized (if you aren't already). This means there must be a login/setup step.
An API call can't be considered authorized just because it came from localhost :)
