Keep in mind the adage "you get what you measure". If you optimize for CTR, you are not necessarily optimizing for user satisfaction/loyalty.
Case in point: Netflix's auto-play feature used to drive me bonkers, so much that I would try other streaming services first. How could they think this feature was a good idea? The only plausible explanation I've heard is that they were optimizing for user engagement. Users click around more to prevent the video from auto playing.
Using String as a ProgType(tm)? That's a paddlin'. We use CharGroup around here, which we are willing to license for a small fee. For a limited time, get 10% off when you license three or more ProgTypes(tm)! Indemnification licensed separately. Contact our enterprise relations desk for details.
And then when you contact them it goes to voicemail, they call you back 9 times 3 days later and sell your email address to everyone under the sun :)
OH and then when theyre about to drop in stock price because they dont know how to deliver valuable products, they use the US government to force other companies to buy their product otherwise the US government will kick that prospective customer out of US markets ^.^
> The bad thing about it is I usually don't realize that I'm getting sleepy until after I've dozed off once.
I'm not trying to be rude, but this sounds reckless. You absolutely should not be driving while you have this issue. Also, consider that you may have a sleep disorder.
As far as I understand it, the policy disallows listings in the short description, and the algorithm wrongly categorized the sentence as a listing because of the Oxford comma.
Your comment made me dig in a little more. I was wrong, it is only fetching the current tab, although it wouldn't need more permissions to see all the tabs.
These `active` and `currentWindow` parameters to query() [2] restrict the results to the current tab. If I remove those parameters and run in DevTools, I seem to get a full tab listing.
Even without `active` and `currentWindow` parameters the extension cannot get urls and titles from other tabs because it has only the `activeTab`[1] permission declared in the manifest. You need more powerful permission for that.
I think with the `activeTab` permission you still get the an object for every tab other the active one, but without access to `url`, `title` and `faviconUrl` properties.
Thanks for checking out anyway. I built this tool especially because all of the others already available were a privacy nightmare.
The beautiful part is that they may have no idea which IP address corresponds to your email until you click a unique link in the phishing email (or load a tracking pixel?).
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 :)
