hrjet

> You can always type /bin/pwd to avoid this and you'll always get the correct path.

Yes, but it affects other programs as well. See the `cat myFile` example in the gist.

By that logic, why not bundle all the popular addons with Firefox? Why only a chosen few?

The complaint is not about WebRTC, but about Hello.

The comments in this thread are going in loops.

  "Hello shouldn't be bundled with a browser."
    "But it is just a small wrapper around WebRTC."
     "Yeah, but it's out of scope for the browser."
       "WebRTC is a web-standard"

> To alter globals, use the window object explicitly.

JS is used in non-DOM contexts as well. Though, of course, if that big a change is being made, a generic substitute for `window` could also be specified.

Wonderful! I don't use Facebook that much, but I hope this helps make PGP more popular among users and services. In particular, I am hoping for banks to start PGP encrypting the reports they send to me via email.

> they'd take my work under my name and bundle their crap into it.

Oh, is that a thing? I was surprised when the Lobo project's admin rights were handed over to some relatively unknown developer. I had a long and confusing discussion with the new project admin here: https://github.com/UprootLabs/gngr/issues/87#issuecomment-86...

> From a mathematical perspective, abnormal balances are essentially negative balances, though in accounting negative numbers should never be used or allowed.

This seems like a bad legacy passed down unwittingly. I am not trained in accounting, but been keeping my books for several years now. I have written a ledger-cli clone and have been using it for the last three years for both personal and company accounts. Using signed numbers works perfectly fine during book keeping. I use the Debit/Credit lingo only when I need to show reports to the pesky accountants. (Fortunately, my main accountant doesn't bother me with formalities).

Yes and No. The client could hop over a bunch of ip6-addresses, since there would be an abundance of them.

As a user of NoScript + Firefox and as a developer of a browser with an express goal of "privacy by default"[1], I am thrilled to see this getting more attention. The more people use privacy features, the more will website developers ensure that their products degrade gracefully when, for example, third-party scripts are disabled. Which will enable even more users to migrate towards a "privacy by default" configuration. And hopefully, this will be a positive feedback cycle.

1: https://gngr.info/doc/introduction.html

The last line threw me off:

> an unauthenticated user cannot access private pages (like edit) or modify the file system with system calls.

System calls? How do they come into the picture? And wouldn't reasoning about system calls require proofs about the kernel itself?

Disabling the user-agent breaks quite a few websites as of today, but I agree, it's a good way forward to break the hegemony of certain websites and browsers.

And we are working on another (gngr) :)

I guess even the offline thing may not be a problem as long as the messages are in a room that is hosted over an always-on server. The bundled server will be able to sync up its history from the always-on server.

You can't bounds check a pointer begotten from &arr[i]. It simply doesn't carry enough information. Moreover, there might be existing C programs that rely on out of bounds access (where they know that the out of bounds access falls into safe memory). So there is no way to implement a C virtual machine with bounds-checking semantics that is fully compatible with all existing C code.

Great point. Lately we have been reconsidering the request manager matrix shown in gngr. It was inspired by HTTPSwitchBoard's matrix, that has a separate column for XHR.

However, like you pointed out, there are other ways than XHR to leak data if JS is enabled.

If JS is not enabled, the kinds of data that can be leaked is fewer (perhaps screen resolution and size).

Would welcome expert comments on our issue tracker: https://github.com/UprootLabs/gngr/issues/90

sandstorm.io

In Java, you can think of lambdas as sugar for anonymous classes. All problems and benefits that are present with anon classes should manifest with lambdas as well.

However, one clear advantage of lambdas is that they reduce verbosity of anon classes.

I was looking at the how it works[1] article but it isn't clear to me how the domain is validated.

Couldn't an MITM between the LetsEcnrypt service and the example.com server request a certificate, then respond to the challenge, and then use that certificate later?

Getting a certificate from StartSSL was similar. The only difference was that there was a human involved in the loop (a mail is sent and the user has to copy paste the contents of the email), but in essence, both the services seem vulnerable.

This seems to be an unsolvable bootstrapping problem, unless some sort of physical verification is done.

What am I missing?

[1]: https://letsencrypt.org/howitworks/technology/

What if there was a setting: "I only provide service for free" / "I accept payments for my service" in your profile?

Such a setting could even be on a per-case basis. Imagine if you helped someone for a good part of a day, and they were ready to return the favor in cash, and you were given the choice to accept or decline it.

The article seems to have been updated pretty heavily. We might have been looking at different versions.

Here's the complete change log: https://github.com/stribika/stribika.github.io/commits/maste...

> A browser that doesn't support cookies

We are working on a browser (https://gngr.info) that supports cookies but doesn't enable them by default for all websites. We also don't enable JavaScript by default. User needs to enable these on a per-site basis. Enabling for all sites at once is also possible if the user so wishes.

In the near future, we also want to support https only sessions (opt-in to begin with and opt-out once https becomes more commonly deployed).

About micropayments, there are many. Flattr comes to mind. But I am sure there are more.

> If I was a developer bringing in several thousand a year on the Play Store

... you would be automatically paying Google with $300 for every thousand of sales. $99 would be redundant.

As they say: you can't have your cake and eat it too.

If Google takes credit for those phones and stamps its logo of approval on the phone, they need to take the blame for the consequences.

> If you have that, there is nothing to crack.

Alice is a system administrator of xyz.com. She has access to the password that Bob uses on xyz.com. By reverse engineering Bob's password on xyz.com, Alice can then attack Bob's account on pqr.com.

I am interested in viewing, but a heads up: the site shows zero entries, even after enabling all first-party scripts and XHR requests. Not sure if third-party scripts are essential, but if they are, consider not depending on them.

I think you are missing a characteristic of lenses called the f-ratio, which is sometimes described as fast or slow. This is not specific to cameras; it is a general term used in optics. The f-ratio is the ratio of the aperture to the focal length. Even telescope lenses and mirrors are described similarly. For example, a telescope with an f/4 mirror can be described as a fast telescope.

Not only that, a lot of the terms have been misappropriated in camera lingo. The camera folks express aperture as an f-ratio, which is extremely confusing.

> there's no need for this to be tied in with HTTP/2.0 at all.

Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.

I wonder if latency can be improved by building upon Mosh[1], rather than SSH.

  [1]: https://mosh.mit.edu/

IIUC, you could probably use KLEE to ease the pain of capturing the state.

http://klee.github.io/

For the MAC, the article suggests an exception to github.com. But it looks like an exception is required for the Kex protocol as well. I see this error:

   Unable to negotiate a key exchange method

If I understand correctly the response from ssh -v -v, github.com only supports the following Kex protocols:

ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss

Edit: By trial and error, I find that this works for github.com:

KexAlgorithms diffie-hellman-group1-sha1