ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > N.A.N.Y. 2012

NANY 2012 Release: NoteMe

<< < (7/13) > >>

justice:
Let me reply to your points individually:

With regards to single point of attack, the last 30 days of messages could be read, not all messages. I could keep multiple accounts so only some messages are compromised in this wurst case scenario.

If a single point of failure is an worry i am happy to add fallback urls to other hosts. I'll make a note.

There is definitely a need for this central setup though: 1) almost no average user knows their smtp details or knows where to find them. 2) I don't want loads of complaints of non functional smtp configurations due to firewalls, typos, edge cases. It reflects badly on me and the program when it is not working. The current setup works for everyone. 3) entering a bunch of configuration details is not a pleasant experience and is a significant barrier to using the program. I have looked at thinderbirds auto configuration documentation and perhaps mail settings are stored in the registry but implementing this might push auto hotkey too far.

And just as a FYI when delivering your regular unencrypted email, it goes through a bunch of servers that can read it.

That said i agree the setup is not ideal, I'm trying to find a balance between the various factors.

I could add the functionality you asked for and make it optional, and I will be supporting two solutions, add complexity to the program, and any time spent on the central setup will not benefit the other setup and vice versa. Sounds like the worst of both worlds.

I'll think about it.

justice:
Also want to say having this discussion is helpful

mouser:
All fair points regarding the disadvantages of smtp configuration.

One solution if you really wanted to keep going with this tool would be to support both methods, smtp configuration for those that cared, and central server script for those that didn't.

mouser:
Two other concerns:

1. Malicious users sending spam using your script+server+account.

2. While it may be similarly possible for your server or the users server to get hacked.. in the former case, *YOU* are going to have a ton of apologizing to do and take a lot of heat if it happens.. Whereas if an individual user has their computer hacked, you are not to blame.  Something to consider.

justice:
Well it sounds like due to theoretical issues I'm having to make the app less practical. I'm a bit demoralised.

Regarding your comments, it's trivial to ban ips based on access logs, I can do that right now. There are billions of webpages on the internet, why do you think hackers will spend the time to hack my webhost just to get at mine? I doubt it will become a target just because a bit of php code contains a gmail username and password. There are bigger problems then for my hoster - who is very reliable. Also there are not many users of NoteMe, so the target is tiny.

So, the code is secure. The only weakness in the current setup is that a snooper can read out the outgoing http call and intercept the message (along with all other unencrypted network traffic) before it's being processed. A simple solution is to encrypt it before sending it. I rather work on that then add SMTP configuration, because it's in my opinion the barrier of email configuration is larger than the debated issue.

But I think now some people will have decided against using the program even though it's more likely spyware will read your outlook mail then target NoteMe. :(

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version