Pinned toot

I forgot this convention when I first setup my instances (though I'm also not sure of the reach on a single user instance).

I develop privacy features for Cliqz and Ghostery browser extensions and Apps, and helped to build the whotracks.me transparency tool.

I'm also interested in the p2p web, specifically DAT, where I'm pushing for dat:// protocol support in Firefox via the dat-fox and dat-webext browser extensions!

DatArchive support is also included, so Dat applications like Solo also work: dat://6af095e72edd6d729bad712ff545c25030111f0c72acf569955939351879f5be/

New milestone - beta build of Cliqz browser with dat:// support built in! Dat urls load natively using the dat-webext extension.

Great news, I've got a #dat archive explorer app sketched out and working with dat-gateway.

Bad news: It only works when debugging remotely and freezes up.

Worse news: I can't debug it since attaching the debugger changes the JS engine that's being used. 😂

github.com/RangerMauve/datmobi

That feeling when an awesome idea gets shot down because of limited browser APIs. Sigh.

RT @evanpro@twitter.com
Fuck reCaptcha.

I am sick of doing unpaid labour classifying images for Google.

We need a captcha widget that contributes to the global commons instead of siphoning value into yet another proprietary lockbox.

SUMMARY OF FINDINGS

HTTP requests to appleid.apple.com are rejected with 502 Bad Gateway if the User-Agent string contains any case variation of "X11; Linux".

That said, I wanna compile a lil' list of people working on #Dat / #IPFS technologies.

I know @aral's working on it as part of Hypha and @darius plugged me to probably the best guide I've seen.

Who else is out here for the distributed Web / #dweb?

The performance has been shown not to hold for adblocking extensions (whotracks.me/blog/adblockers_p), and there are many other problematic webextension APIs w.r.t. privacy.

The solution to these issues should be institutional, not technical. Google should impose performance constraints on extensions, and audit what data extensions are sending home. However, looking at the rampant malware on all their stores, this is something they're unlikely to do, so instead they'll nerf extension's capabilities.

Disagree with this article's thesis that the Webextension webrequest API should be removed.

By moving to a declarative blocking API you are limiting the possible ways for extension to function to blocking and redirecting. This is a very narrow use-case, based on the current prevalence of blocking extensions.

But this is not the only way to solve problems such as blocking ads and improve privacy, as shown by privacy badger and Cliqz' tracking protection.

ctrl.blog/entry/removing-webre

A product's privacy claims are only as good as its default settings.

Providing options to change the default privacy-violating settings in some "Advanced" section doesn't make your product a privacy-respecting one.

#Privacy

@liaizon Mastodon would need to be able to speak over the dat protocol and make the query to confirm. so we'd have to add a dependency to Mastodons server of a library that can essentially do "curl dat://" and then use that to confirm the link

Great post by a colleague on benchmarking adblocking engines. The level of optimisations in these engines is incredible! whotracks.me/blog/adblockers_p

I made a thing. 😀

This uses the work I'm doing on dat-js to load content from
#Dat archives using either WebRTC or a websocket gateway. This is a proof of concept and I'm still playing around with performance and the API, but I'm liking it so far. 😊

ranger.mauve.moe/dat-js-exampl

#p2p #dweb

Was excited about this talk almost more than any other at #fosdem.

@ExodusPrivacy@twitter.com is doing amazing work in identifying surveillance patterns in native apps on Android.

And their learnings are set up to be dev-ready, easily used in your own projects.

Donate to support them!

I forgot this convention when I first setup my instances (though I'm also not sure of the reach on a single user instance).

I develop privacy features for Cliqz and Ghostery browser extensions and Apps, and helped to build the whotracks.me transparency tool.

I'm also interested in the p2p web, specifically DAT, where I'm pushing for dat:// protocol support in Firefox via the dat-fox and dat-webext browser extensions!

Over the last couple of weeks we've developed a emulator, which enables the profiling of browser extensions outside of the browser by running them in a node VM. Already we've identified significant performance gains for @cliqz and @ghostery: github.com/cliqz-oss/webextens

So in summary: Google has good reason to clamp down on the extensions API, there isn't really a standard that has any teeth, and so Google will probably move forward and I imagine extension authors and other browser vendors will just have to deal with it. Fin.

2. Platforms tend to craft their APIs to match what they want you to do. Ghostery on Safari and iOS is much more limited in terms of the privacy protections we can deploy because their APIs only allow certain use-cases.

Now Chrome is considering moving to the same model for blocking requests, which would mean much of the tech I develop could no longer run on chrome: bugs.chromium.org/p/chromium/i

Show more
Mastodon

macbeth.cc is one server in the network