The Android Flock client works with any standards compliant WebDAV/CardDAV/CalDAV server. There is nothing stopping anyone from running a server of their own, at which point you can do anything you want with the server including charge for its use.
Right now the initial sync does take an unreasonable amount of time, I definitely agree.
After first sync you will never have to experience a sync operation anywhere near the length of that but it is a bad first experience to have with the app. Very close to the top of my TODO list is "support bulk upload" which will cut the initial import time (and bandwidth) considerably.
Soon we should be able to upload entire address books and calendars in one POST request, working on it :)
not to be a bummer, but it doesn't seem like anything special was done with this special purpose hardware. why go to the trouble to engineer and advertise this as a piece of security enhancing hardware when it's really just "PrivOS"? also, any plans on open sourcing "PrivOS"?
did I miss something in the writeup? OSS modem firmware, OS wifi chipset, anything hardware or firmware related?
Kind of-- some older code was (is?) copyright WS, newer code is OWS, in both cases everything is GPLv3 and all future code will continue to be OWS & GPLv3.
We've got a browser extension in development, with the possibility of using an email address instead of a phone # as ID-- no promises on time line though.
There is no way that this attack method is profitable if the attacker is fronting the cost of manufacturing. This leads me to believe that this article is incorrect or fabricated, or that this is a seriously interesting attack on a iron manufacturer.
I'm inclined to agree with you, generally speaking simplicity is security. Also, I believe that the "secure JS in-browser crypto is impossible" argument is entirely bunk in this context-- people need to stop reciting this compulsively and take the time to think each situation through.
Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript.
The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model.
Last month's cryptopary had a really diverse, really excellent turnout. These will continue to happen every 3rd Sunday. Bring a friend, share the knowledge :)
I was robbed in West Oakland over the summer while developing the app. Funny thing, I actually had the app installed on my phone at the time it was stolen and made a bunch of design and feature changes after the fact.
I think only the highest of Mozilla and everything they stand for.
"You will take a job somewhere else some day and experience great anguish when it is significantly less awesome."
What I'm trying to convey is that I don't believe that anyone need make this compromise. Mozilla is awesome, other organizations are awesome, some freelance gigs are awesome. You can be a software developer without putting yourself through anguish, it's just a matter of priorities.
You're a software developer which means you have the opportunity to work virtually wherever and whenever you want. You can write software on a sunny day in the local park, inside a tent in the midst of an Arctic storm, or aboard a boat in the middle of the Atlantic.
A laptop can be purchased for $200 and internet can usually be found free. There is no reason to compromise on a less than exceptional job unless you want to live in the idealized city apartment and collect a sizable salary.