hjlklhj
This is still bad since they now will have a list of possible usernames on the system but not nearly as bad as getting access to the hashed passwords as well.
The metric (si) unit of time is the second. To "tell time in metric" one would use si prefixes, as is done in e.g. Vernor Vinges A Deepness in the Sky.
One hectosecond would be approximately one minute, a kilosecond ~15 minutes, 100 kiloseconds ~1day, 1 megasecond ~2 weeks, 31.54 megaseconds in a year, ...
(generally is emphasized by me)
The argument can be made that showing someone ads in return for services is offering things commercially. C.f. free tv channels with ad-breaks.
>>If you can mitm the dns or ip you can still do this even with https.
>Strictly speaking you'd need a compromised DNS and a compromised CA (possibly with a wildcard certificate). Certificates provide assurance of identity as well as encryption (that's why public key encryption works). No matter where the connection comes from. (EDIT: If I compromise DNS for an SSL secured site I only get half an attack.)
My comment here was for the "the link to the app that does the syncing could be blocked to maintain a vulnerability" argument. That you don't need a CA for. Just throw a NXDOMAIN from the dns.
edit: please note that I very much agree that update checks should be over https. It's just that I think that it's not a panacea and should be accompanied by e.g. code signing, enforcing updating version, etc.
If you can mitm the dns or ip you can still do this even with https.
> downgraded to a vulnerable version
does the app allow "upgrading" to a lower version number automatically?
> or potentially compromised
the app enforces signed updates, no?
That said, they really should get https going for the updates.