hrjet

Compared to RaPi it looks bad, but if you compare OrangePi to say ESP8266, it looks like a good deal (for certain projects):

* OS and scheduler v/s low-level partially documented SDK

* 2GB RAM v/s 100s of KB in ESP8266

* 16GB Flash v/s couple of MB Flash on ESP8266

* All other goodies: 4USB ports, Audio/Video, HDMI, Camera, SATA, IR

* 15$ v/s 5$

You could give FLIF [1] a try. With the help of Poly-FLIF [2] you can render it in the browser. Don't forget to try the lossy mode, it gives better compression with negligible loss in quality.

1: http://flif.info

2: https://github.com/UprootLabs/poly-flif/

They are more akin to "processes", because they don't share state with each other or the main event loop.

Yeah, indeed, this idea is not meant for typical users; only those who have script blockers and the like installed in their browsers. At present, even such security concious users can be deceived with layout and URL masquerades.

Corporate proxies / firewalls.

> and/or have a lighter browser (without canvas, webgl, webrtc etc.) with better defaults (ie. no hardware access, location, notifications, cookies, history, etc.) for opening links, private browsing etc

We are building one [1]. Contributions are welcome! In the meanwhile, the ungoogled-chromium project in combination with uMatrix is I think a great way to transition away from Chromium.

[1] https://github.com/UprootLabs/gngr

There is one more called Firefox Debloat: https://github.com/amq/firefox-debloat/

... though it hasn't been recently updated.

We are developing `gngr` in the belief that privacy should be engineered into the browser, not worked around:

https://github.com/UprootLabs/gngr

Isn't Qubes OS just a hypervisor? The hosted OSes shouldn't leak that they are running under Qubes.

Yup, its inspired by `ledger` and the syntax is similar to a large extent. The focus is on cross-platform support, and a more declarative style (order of specifying transactions shouldn't matter).

A detailed comparison is missing, however.

We are designing a solution in gngr here: https://github.com/UprootLabs/gngr/issues/219

In essence, the resolved address of a request will be checked if it lies in a reserved block. If so, further policy checks will be made for the resolved address, and the IP address will be pinned for that HTTP request.

Would appreciate feedback here, or on the issue.

gngr[1] is a browser that champions privacy. It is a complete written-from-scratch project, and not just a wrapper around existing layout engines.

Our current logo and website design, if you can call it that, is a developer created, few days effort. We would be very happy with some professional design help.

Notes:

* gngr is short for ginger, the spice.

* The theme would be "spicy, but not shiny".

[1]: https://gngr.info and https://github.com/uprootlabs/gngr

FLIF promises to be silent as well. It also has a ~50KB JS decoder [1].

  [1] https://uprootlabs.github.io/poly-flif/polyflif-sample.html

Although FLIF, the format, is lossless, the FLIF encoder has an option to lossily encode the input. It works by eliminating the differences between the predicted pixel and the actual pixel.

When encoded lossily, FLIF is competent with JPEG on still images, and ofcourse very competetent with GIFs.

Promises can be helpful in a pure CPU bound workload as well: they help to avoid blocking the main thread, by yielding more often. This is typically done by breaking a long running computation into a series of sub-computations that are scheduled on a timer, and the top level API returns a Promise that completes when all computations are over.

The same goal could also be achieved with multiple threads (webworkers for example). But the promises and async/await syntax is more convenient.

We are building one in Java https://github.com/UprootLabs/gngr

This seems simliar to what I had developed:

http://nlq.lavadip.com/servlet/about

Although, kueri seems more polished, and the ability to auto-complete mid-sentence is pretty neat.

We do want to take an approach like this in gngr(1). We already have fine-grained permission control in the Request Manager (inspired by uMatrix, nee httpSwitchBoard).

But your question is about even more finer control. Some thoughts:

* I believe some of these APIs shouldn't be implemented at all, or should have very limited precision. Eg, Battery Status need not be implemented at all, or if implemented, should return just two values: [high, low].

* In our Request Manager, we could add an extra column for advanced APIs. This would include, for example, Canvas, WebRTC, etc.

* @captainmuon's idea of having two different profiles (document/app) is interesting. Though the choice of profile should be on client side. The default should be conservative (document) and the user should get to choose if a site should be promoted to app or not.

[1] : https://github.com/uprootlabs/gngr

There's no need to standardize here? This could be implemented purely on client side.

> It should also be noted, for some time similar attacks have been possible via html/css [1]

As it happens, this particular attack doesn't work in gngr [0]. The example uses an absolute positioned div to put extra text out of viewport, which is not picked up by gngr when selecting text.

gngr also doesn't enable Javascript by default, so attacks such as that described in OP are not possible from random site visits. (I recommend uBlock / uMatrix for other browsers).

However, the attack surface is really quite large here. CSS directives such as `opacity: 0.001` could be easily used to mask extra text.

  [0]: https://gngr.info/
       and https://github.com/UprootLabs/gngr
  [1]: https://thejh.net/misc/website-terminal-copy-paste

As I see it, Javapoly is a layer above Doppio.

As a very crude analogy: shells and editors make it easy to use the filesystem. But we can't contribute the shell / editor to the filesystem! They sit in different layers of the stack.

> What is the difference of this to doppio? A new approach from some of the doppio authors?

(I contribute to both Javapoly and Doppio)

Javapoly tries to make Doppio easier to use (in my subjective opinion):

* easier loading of jars, classes and Java source code * a promise based async interface to Java methods * automatic marshaling of primitive values between JS and Java lands * a proxy based interface into the Java namespace.

You can do it with a couple of lines of shell script too, using the xcalib utility:

https://gist.github.com/hrj/e9ed0d73d2daaa98b2d2

Been using that for more than an year with great results.

I also have another version of it: https://gist.github.com/hrj/6561271

(this version cuts the green and blue equally)

> Why is that so good..

It encourages tinkering which is especially important for students.

Also, many other general benefits that open-source brings. For example, open source code is more trustable than closed source.

Also, Matrix.org

Open, federated protocol, multiple client and server implementations, integrated IRC bridge.

SEEKING WORK, India, REMOTE

# Familiarity with:

* Java eco-system, including Java 8, Scala and Kotlin languages.

* Experience developing server, desktop and mobile (Android) apps.

* Familiarity with systems programming (networking stacks, video codecs, Linux kernel mode programming) with C, C++, in a past life.

* I can also find my way around JS, python, SQL.

# My Github profile: http://github.com/hrj

I am passionately involved with some open-source projects for more than an year now, and need some moolah to keep going. Looking for short-term gigs (less than 6 months).

The cost of living is low here; so my rates are reasonable. Email address in profile.

It's not eager. The | combinator takes lazy parameters (called pass-by-name in scala). So it essentially gets translated to:

val e = operator_pipe(() => p, () => e)

Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.

I agree. One thing that is sorely missing, for example, is a way to define recursive values.

In Scala, to express a recursive parser combinator:

val e = p | e

You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.

While I like the mechanism, I am not too certain about the policies. From the paper [1], they use "a subset of approximately 1500 domains from Disconnect’s privacy-oriented blocklist to identify these unsafe origins". Further, they update the block list every 45 minutes. Which means, a service which wants to track the user can use domain names outside that block list of 1500, and change it every 45 minutes (in case it becomes popular and the block list catches up).

Am I understanding this right?

Aside, I realize that there are no easy solutions for this. As the paper also says, it is hard to identify which requests belong to third parties because of the prevalent practice of using third-party CDNs.

I believe one approach is to disable cookies, javascripts and other sensitive functionality from all third-parties, without any biases or curation, and to provide the tools to enable them selectively. The only drawback is that it won't fly with non-tech-savvy users. However, I think the tech-savvy segment is large enough and growing, to make it worthwhile.

This is the approach that the uMatrix addon, and gngr, the browser that we are developing, take. It would make me very happy if other browsers integrate such a facility within them.

[1]: https://kontaxis.github.io/trackingprotectionfirefox/resourc...

Couldn't this mitigated by user-agents introducing random, Poisson distributed delays in all cached responses? The peak of the distribution could be made user configurable to make it further difficult to predict a user-agent.

From page 19:

> But all those other languages include explicit support for null pointers for a good reason: they’re extremely useful. [....] The problem with null pointers is that it’s easy to forget to check for them.

There is no inherent reason for that; just that mainstream languages which support `null` haven't been checking `null` usage. Some of the recent ones do. For example, Kotlin has non-nullable types by default, and null types have to be explicitly marked and checked for null-ness.

Even for Java, null analysis is built into Eclipse with the help of annotations. Though, ofcourse, it would be far nicer to have it baked into the language.