smarx

I think it's Kernighan, actually: https://www.laws-of-software.com/laws/kernighan/.

The ship has sailed on this term of art, but as a native English speaker, I agree with you that it's ungrammatical. I would use a hyphen, though: "physics-based." This answer agrees with you (and me): https://english.stackexchange.com/a/428679.

Here's one way to think about _why_ it sounds wrong. "Physically based" would mean that "physically" is the answer to the question "How is it based?" To a native English speaker, that question sounds odd. A more natural question is "What is it based on?" To answer that question, you need a noun: "It's based on physics." Hence the construct "physics-based," like "evidence-based medicine" or "merit-based scholarships."

I believe you failed the CAPTCHA. I assume the bottom right is the only correct answer.

Truly secure entity just wouldn't have private keys on a server at all.

They don't. They have your encrypted private key, but there's no need to keep that secret. (The decryption key is derived from your password, so the password needs to be strong and secret.)

Such agency can force PM to modify login process to derive password from submitted form, or to just switch private keys for non-encrypred ones, because the user won't even notice it.

Yes, definitely. It's hard to trust self-updating software (like JavaScript in the browser), particularly if you're concerned about targeted attacks. But creating your own private keys and then entering them in the browser wouldn't help you at all against that sort of attack. You would instead need a different type of client that could be trusted somehow not to leak your private key.

It's not uncommon for services like this to offer a downloadable version of the web client so you can pin a version and audit the code as needed. I think maybe https://github.com/ProtonMail/WebClient is that for ProtonMail? If so, you should be able to verify that code and then use that. The fact that an encrypted copy of your private key will live on ProtonMail's servers shouldn't bother you.

That experiment shows that whatever is stored on ProtonMail's servers plus your password is sufficient to decrypt your emails. This could be explained by the private key being derived from or encrypted with your password. ProtonMail's documentation says it's the latter (https://protonmail.com/support/knowledge-base/how-is-the-pri...):

Your ProtonMail private key is generated in your browser. Before sending the private key to the server for storage, we encrypt it with your password (or mailbox password if you use two-password mode). This ensures that you and only you can use your private key.

So the only remaining question is whether ProtonMail has access to your password. If they do, they can decrypt your private key and then decrypt your emails. Often, passwords are sent in plaintext to a server for authentication. But ProtonMail uses the Secure Remote Password (SRP) protocol so they never see your password: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco.... (source: https://protonmail.com/blog/encrypted_email_authentication/)

Of course, there are other threats to worry about, such as ProtonMail changing their client-side JavaScript to exfiltrate your password. But the system as they've documented it does not appear to have any way to decrypt your email server-side short of guessing your password.

It's worse than that. They could just throw away all the sales from this contract, since it's not connected to anything.

They also failed to verify source code for the contract: https://etherscan.io/address/0x3c7767011C443EfeF2187cf1F2a4c..., and the source code on GitHub is missing a file ("Ownable.sol"), making it difficult for anyone else to verify what source code is actually running.

I suppose the lack of verified source code doesn't matter, given my first point. People who are buying are placing a lot of trust in the "Fuel Bros Innovation Team."

As far as I can tell, the IV is randomly chosen, as you would expect: https://github.com/cryfs/cryfs/blob/master/src/cpp-utils/cry.... Did you see something different?

Assuming the 128-bit IV is indeed randomly chosen, after encrypting a trillion blocks, you would have roughly a 1.5E-15 (on the order of a quadrillionth) chance of hitting a collision.

Unless I'm mistaken, even if you hit that one-in-a-quadrillion lottery, the result is that the two blocks encrypted with the same IV are more crackable (because you can XOR them together), not that the key itself is easier to obtain, right? (My understanding is that AES is resistant to known-plaintext attacks.)

I think this is what you're asking for:

    <div id="root"></div>
    <script src="https://unpkg.com/react@16/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
    <script src="https://unpkg.com/babel-standalone@6.15.0/babel.min.js"></script>
    <script type="text/babel">
      ReactDOM.render(
        <h1>Hello, world!</h1>,
        document.getElementById('root')
      );
    </script>

You've given a clear, easy to understand example of something, and you've told people that this something is a zero-knowledge proof.

Anyone who doesn't know what a zero-knowledge proof is will give you positive feedback, because they had an easy time understanding the example you presented.

People who do know what a zero-knowledge proof is will correctly point out that the thing you described is not a zero-knowledge proof.

I think this explains the gap you're seeing between the feedback here and the feedback in "less technical forums." It's difficult to come up with real-world examples of zero-knowledge proofs, but there are two good examples on Wikipedia and one here (the "Where's Waldo?" example).

Just to close the loop here, we’ve updated the page to include a checkmark for 2FA in the Pro column too. Again, all account types can use 2FA (and we recommend that they do!), and teams can additionally require 2FA for all their members.

See the updated page here: https://www.dropbox.com/plans?trigger=nr.

I'm not 100% sure what that is about, but I'm pretty sure it relates to new functionality for migrating data from existing file servers.

The API at https://www.dropbox.com/developers works for all account types. (Note that there are endpoints specific to team accounts when the functionality only makes sense there, like methods to add or remove members from a team, etc.)

Engineering Manager at Dropbox here. Sorry for the confusion! This is an error on that page, presumably some miscommunication between groups at Dropbox. 2FA continues to be an available feature for all Dropbox users. The only difference between plans is that team plans allow administrators to require 2FA for all members of the team. That page will get updated soon to explain that feature properly.

See https://www.dropbox.com/help/363 for more information.

https://www.site44.com (I'm a founder.)

The first display using this platform is in the 8th Avenue lobby at the Google NYC office.

If you mentioned what company you're talking about, it might be easier to get help. Is there a reason you're not doing that?

As JacobAldridge points out, the "authority" in this case is the owner of the logo being used, so you'll need to find contacts at each company. On the Dropbox side, you can email brand@dropbox.com in general with questions about brand use. If the logo use is truly inappropriate, that team can decide whether to reach out to the startup.

It's not in v2 yet (coming soon!), but check out /log/get_events [0] in v1. I'm not sure that it will cover what you want if you're looking for file changes. That might be better served with webhooks, /files/list_folder and /files/list_folder/continue. Feel free to post on the developer forum if you want more help! [1]

[0] https://www.dropbox.com/developers-v1/business/docs#log-get-...

[1] https://www.dropboxforum.com/hc/en-us/community/topics/20020...

And Dropbox has one for API v1: https://github.com/dropbox/dropbox-js. There will be one for v2 as well.

FYI, endpoints that could actually take advantage of caching (e.g. downloading a file, preview, or thumbnail) do support HTTP GET with ETags.

Thanks for the feedback! This is definitely already being tracked as a feature request, but I don't have anything to share about if/when we'll add comments support to the API.

Our goal is definitely to give administrators the control they need through the API, but I'm very willing to believe there are things we're missing. :-) Is there something specific that's not already part of our Dropbox Business API? (https://www.dropbox.com/developers/documentation/http#teams)

Stay tuned for more details! The short answer is that yes, you'll be able to do that, but we haven't published that API description yet.

Looking at the code, it appears that this will only work for Dropbox accounts that have a public folder (users who signed up prior to October 2012 or paid users who have specifically enabled the feature).

(See https://www.dropbox.com/help/16.)

Seems like a useful tool; thanks for sharing it!

Two questions:

1) What's the diff logic? At first glance, it looks like JSON is reformatted (maybe canonicalized in some way) and then a line-by-line diff is applied. Is there more to it? Since the tool seems JSON-aware, I was surprised to see an added trailing comma up as a difference.

2) Do you have plans to expand the kind of HTTP requests users can make? It would be nice to use different verbs, headers, and request bodies. Runscope has a similar tool[0] built in that I believe (haven't tried it yet) allows a bit more flexibility, but it would be nice to have a standalone tool available.

[0] http://blog.runscope.com/posts/comparing-http-requests-using...

(I'm the blog post's author.)

Concretely, it means we emailed everyone by hand with a Datastore API app that had a non-trivial number of users and offered to help. (If anyone didn't get an email, you might only have a couple test users, but feel free to reach out to us yourself.)

With most developers who respond, we're digging into their data model and trying to suggest alternatives (possibly files in Dropbox or possibly alternative services like Parse and Firebase).

1Password doesn't use the Sync API.

Blog post author here. It definitely seems that I worded that part poorly. I hope the comments on the blog help clear this up, but it's a bit hard to talk about in the abstract.

If you have an app that's using the Sync API, feel free to reach out to talk specifics.

The new API does support GET for requests that are cacheable (e.g. fetching a file or thumbnail).

The RPC-style endpoints all use POST and are not cacheable.

Is there some benefit to implementing it as a GET instead?

See also https://www.dropbox.com/help/8807.

Oops, you're right! Here's a fixed version (just prefixing the timestamp to the value to make sure it's always unique). Of course, this entire class makes the assumption that you never write twice with the same timestamp. (That's hard to guarantee if you're actually using time instead of something strictly increasing.)

    class TimeStore:
        def __init__(self, redis_client):
            self.redis_client = redis_client

        @staticmethod
        def timestamp(time): return (time-datetime.datetime(1970,1,1)).total_seconds()

        def set_value(self, key, value, time=None):
            if time is None: time = datetime.datetime.utcnow()

            timestamp = self.timestamp(time)

            self.redis_client.zadd(key, timestamp, '%d:%s' % (timestamp, value))

        def get_value(self, key, time=None):
            if time is None: time = datetime.datetime.utcnow()

            for item in self.redis_client.zrevrangebyscore(key, self.timestamp(time), 0, start=0, num=1):
                return item.partition(':')[2]
            return None

        def cleanup_before(self, key, time):
            self.redis_client.zremrangebyscore(key, 0, self.timestamp(time))