p0peax

In WatermelonDB's case, I bet most people will run it using React Native (ie mobile apps for iOS and Android), so that wouldn't really be an issue.

On the other hand, sql.js (https://github.com/kripken/sql.js/) packs to about 2,6MB (see http://kripken.github.io/sql.js/js/worker.sql.js). I don't know about performance under heavy use of that. I don't know what SQLite backend WatermelonDB uses from ReactJS either.

They still can't run iOS apps from the App Store. They are encrypted when downloaded and only decrypted at runtime. Decrypted apps can be offloaded from a jailbroken phone and then re-uploaded to a pirate store though.

It is absolutely not "How GPS can track you, even when you turn it off". It's an article for the average consumer and the title should've been "how your location can be found even without GPS". This is just a clickbait-title.

Use any tool to monitor if the microphone is in use or not and you'll quickly find that Chrome or any other Google software isn't listening to your device.

I don't know what's up in this video, but I have a hard time believing it to be true. Without being able to present any evidence of it, I'm still sure he's fudged with the video.

We are right to be sceptical and to reassess our privacy these days, but we have to be chasing the right things. It's in these big companies' favor if we're going after the wrong things, because it means we're still ignoring the shady things they are doing.

I think the tooling on front-end vs. backend has something to do with the end of the pipeline. Backend systems can be developed using multiple languages and frameworks that will ultimately run on only one platform. Front-end can be developed with multiple languages, but will ultimately be transpiled to JavaScript and rendered as HTML/CSS. Front-end has to accommodate multiple platforms and browsers.

To me it also feels like the "modern" tooling for front-end is created for front-end developers by backend-developers.

This is a reason to be wary of loading external images by default in mail. I don't know if they do, but spammers could quickly identify active e-mail addresses using this technique, so simply opening a mail could mean you would get even more spam, because your e-mail address is now marked as active.

Error handling on signals are such and easy thing to put off and "do later." Even though the signals often will tell you something about how to error correct.

In one way I feel like the title for the paper is not correct, in the conclusion, they state that testing all these signals is not straight forward. But in my experience, a lot of critical failures could be prevented with very simple automated testing.

Using ReactOS as a source code reference when analyzing malware is something I never thought ReactOS would bring to the community. I makes me realize that it's good to have open-source projects like that so we can make heads and tails of systems that are affecting us every day.