lenish

RFC7457[1] and Wikipedia[2] offer an overview of many of the attacks on older versions of TLS. Some of those attacks have been mitigated to varying extents in implementations of the affected versions. TLSv1.3 is meant to resolve completely as many of these issues as possible.

When using older protocol versions, it can be complicated to validate that the TLS implementation you are using has the necessary mitigations in place. It can be complicated to correctly configure TLS to minimize the effects of known attacks. Doing that properly requires a fair amount of research, threat modelling, and risk assessment both for yourself and on behalf of anyone accessing your website or service.

IME, TLSv1.2 is still a big chunk of legitimate web traffic. It has been steadily dropping since standardization, and TLSv1.3 is the majority by a wide margin from what I can see. I wouldn't be surprised to see some websites and services still needing to support it for a couple years more, at least, depending on their target audience.

[1] https://tools.ietf.org/html/rfc7457

[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#Attac...

    func foo() (*SomeType, error) {
        ...
        return someErr
    }

    ...
    result, err := foo()
    if err != nil {
        // handle err
    }
    // handle result

    type Result struct {
        Err error
        Data SomeType
    }

    func (r *Result) HasError() bool {
        return r.Err != nil
    }

    func bar() *Result {
        ...
        return &Result { ... }
    }

    ...
    result := bar()
    if result.HasError() {
       // handle result.Err
    }
    // handle result

Not GP, but I've sometimes found libraries implementing similar concepts differently causing issues.

E.g.

    libraryA.Result struct {
        Err error
        Data SomeDataType
    }

    libraryB.Result struct {
        err string
        Data SomeDataType
    }
    func (r libraryB.Result) Error() string {
         return r.err
    }

I concede that there are probably scenarios where this design makes sense within that context. I typically find that either I care about a single error and terminating the computation, or I don't care about errors at all. In the former case, the primitives in the sync package (or just an error channel which we send to once and close) are adequate. The latter case presents no issues, of course.

At $work we definitely have examples where we care about preserving errors, and if that tool were implemented in Go a solution like a Result struct containing an error instance and a data type instance could make sense.

I'm not sure why you'd use a class like this in Go when you have multiple returns and an error interface that already handles this exact use case.

Forgive me, as I haven't used signal, but I don't see how whether they are sitting next to you or not changes the problem.

If I can generate a key that hashes to the same value as your key, I can convince anyone I am you. If I can generate a second collision for a third party's key, I can convince you you are talking to that third party, as well. Generating hash collisions is, as I understand it, pretty well modelled with the birthday paradox (and variations like the one I linked). Physical proximity seems entirely unrelated.

If we're talking about the actual hash signal uses for this value, then sure, but talking about the number of digits displayed isn't even the right thing to care about, since they're using SHA1 for the hash AFAICT: https://github.com/WhisperSystems/Signal-Android/blob/3.0.0/...

It is a similar problem, however: https://en.wikipedia.org/wiki/Birthday_problem#Same_birthday...

reducing it to 98 bits?

Did you mean 198?

198 bits is entirely reasonable assuming a brute force attack is the only option. Were it not we'd be in a panic over AES-128 and AES-192. :)

A simple-ish way of subsidizing some of that effort is to just make a subreddit for arxiv submissions and link to the comments section from arxiv-sanity for a given paper. You still don't tie into other communities, but if someone has something to say about a particular paper it provides a straightforward mechanism (until the, what, 6 months at which point the submission is archived and can't be voted on or commented on any further). You only need a couple moderators and some strict rules (automoderator rule to only allow submissions from the arxiv-sanity user, etc).

Yeah, I read that comment. I'm hoping they can give us at least some form of tooling around this, though. The inability to do even basic things as a mod seriously sucks.

opt-in home pages that are tailored at specific audiences. The standard one is pretty low quality.

How is that distinct from multireddits?

more detection/policing of voting rings and vote fraud in general

One thing that'd help with this is better mod tooling for detecting when it's happening on a reddit you mod.

It's referring to a kind of display driver in which frames are rendered as bitmaps into memory then that bitmap will be rendered to a screen. Fonts for such drivers are, AFAIK, always bitmap fonts.

https://en.wikipedia.org/wiki/Linux_framebuffer

What problem is this trying to solve? Having a single webpage with full control of the device, but limiting how many resources the ads on it can take?

Restricting ad resource usage is the only non-niche answer I've imagined. You could make arguments that games could prioritize input/networking over refresh rate using something of this sort, but it seems like there should be a better mechanism for those kinds of applications -- especially since this proposal would require you to separate your JS into multiple subresources to take advantage of it AFAICT.

Assuming their motivation was in fact to restrict resource usage by ads, I'm not sure this is the right way to go about it. Perhaps if your ad network can't serve resource efficient ads you should change ad networks (or pressure your current ad network to improve).

Banning a single service such as WhatsApp is not a solution to this problem.

Generalizing this argument a bit, banning encryption is also not a solution to this problem. The cat is, as they say, out of the bag, and unless we're going to burn every cryptography book and remove every website documenting cryptographic methods or hosting cryptography code, there's no putting it back [1].

1: Presuming the development of effective post quantum cryptography cannot be prevented and distributed, which considering the current state of PQC seems unlikely.

It would depend on the website's resources and services. For example, a layer 7 DoS which just queries an expensive endpoint on the website over and over may not need high traffic volume to overload the website's systems.

automatic JSON but no other serializations

Maybe I'm missing something, but? https://golang.org/src/encoding/xml/example_test.go

https://github.com/golang/protobuf uses this as well.

There are platform specific APIs for that functionality. You can't necessarily do everything on each platform that you can on a given platform, but if you want some iOS or Android specific behavior you can implement it.

You might have to wait a bit for new releases for features that come out in new OS versions, but that's not terribly surprising.

For anyone else wondering, they're using AES-CBC with no MAC: https://github.com/meshbird/meshbird/blob/master/secure/cryp...

Should at least use a decent HMAC construction, but would be better to switch to AES-GCM. There's an issue filed for it: https://github.com/meshbird/meshbird/issues/4

they lay an exclusive claim on the word ethics when applied to software.

I'm not sure that's a fair characterization. They've defined an ethical framework for software and then they discuss things being ethical or not within that framework.

Anyone is free to use a different ethical framework and decide if an action is ethical or not within that framework instead.

It's not strictly about targeted attacks. There are people who modify unencrypted content that passes through their system regardless of what content it is. There have been several presentations on this topic, but I'll link the slides for one [0]. Here's an article about an ISP injecting ads in case you don't think this sort of thing happens in real systems [1].

[0] https://www.defcon.org/images/defcon-17/dc-17-presentations/...

[1] http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...

That's not actually true. There have been several documented examples now of people injecting stuff into HTTP requests when they pass by (ISPs injecting notifications, ads, people running proxies injecting malicious javascript, etc).

The key(s) used for the cipher would need to be randomly seeded in some way that an attacker could not easily guess (e.g. with a different CSPRNG).

Edit: And for hash functions, you can generate some random bytes that you append the counter to before putting it through the hash algorithm. The same as above, if those bytes are hard to guess then the construction should be safe.

I don't have access to an environment like this, but wasn't GNU Parallel designed for job scheduling across clusters? I'm not sure how tolerant it is of having the processes on the remote nodes killed, since I've never had to deal with that. I'm curious how much of the problem it solves, though.

So much layout and presentation is done with JavaScript anyway that it would make just as much sense to get rid of CSS and extend and standardise on something like jQuery-but-better to create an evolving cacheable layout library that bypasses browser quirks and uses exactly one common versioned codebase.

The concept of executing untrusted code is entirely antithetical to security. Javascript, or any Turing complete language, or perhaps that even is too precise a constraint, is a remarkably bad idea for setting the style of anything that is otherwise static. There's no good reason that text and images need be stylized via a proper language rather than static, non-executable statements.

As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever.

I keep finding sites that simply don't work at all in Firefox with NoScript. Many of those sites are primarily just text and images which don't display otherwise. It's completely insane from a security point of view.

In the HTTP2 world, extra requests don't add any additional latency.

They don't add any additional TCP connection latency, sure. I think it's a bit unrealistic to claim there won't be any congestion of the multiplexed stream which causes additional latency.

I think I'd heard that it even uses a common compression dictionary for all requests, which means that boilerplate code that's duplicated between components will get compressed away.

I may be misremembering, but I thought that was just for request headers?

I don't disagree on any particular points. When I first read about it and started playing with it I definitely felt like my expectations were set to something other than what IPFS actually provides.

That said, I think systems of this nature are worth pursuing and perhaps IPFS itself can be improved for more general purpose use cases. For my part, I think it'd be awesome to be able to write some html, css, make some images, `ipfs add ~/website` and then be able to link anyone my content and have reasonable guarantees of it's existence for the rest of my life. I can host my own websites, but it's not a particularly enjoyable experience.

This is a lot more convenient than someone having to explicitly spider it etc (although a combination would probably work/be good idea -- eg: an IPFS "dmoz.org" where authors could register content index-pointers for others to spider/download into their IPFS nodes -- and index for search).

IIRC it's possible to follow announcements of new hashes on the network and retrieve them automatically. I picked this up from #ipfs on FN, I believe, so I'm not 100% sure about it. Doing that would make an IPFS search engine fairly robust (and interesting to build, actually).

But say if popular browsers by default used IPFS as a cache, that way if the original publisher goes away the content could live on, as long as the content is popular.

That is my main issue with the way IPFS is being marketed, as it were.

It is not a "Permanent Web" if the only content that is permanent is popular content. Old links will still break, because old links are generally less popular. Old websites will simply vanish, even ones that are otherwise maintained on the current web.

In particular, applications like this post itself, that are part backup part publishing, aren't great applications of IPFS because your images are just hosted off your home internet connection. Power outage? No data. ISP issue? No data. Hardware failure? Hope you had a real backup. Basically, why would I choose IPFS, which is in this case equivalent to self hosting, over flickr, instagram, etc?

Edit: I'd be remiss to not refer you to toomuchtodo's comment below. Were a service like the Internet Archive to take part in IPFS then it would help with some of my above concerns. However, it's not really IPFS that is making the permanence possible so much as the Internet Archive in that circumstance.

It caches things locally (in ~/.ipfs/blocks), so you'd have to request it from a secondary system to get it even on another node. However, my understanding is that if that second system left the network and you left the network the data would still be lost.

You need a third party to request the data and not leave the network to keep the data around.

Given either the third party reliably remains in the network (e.g. the Internet Archive) or you can consistently get new third parties to request the data and cache it then it will remain in the network. The latter does not seem particularly reliable to me, however.

Well, it doesn't matter so much how many hosts join the network. You still need to convince some members of the network to view your content at least once in order to distribute the data.

I suppose you could argue that nonvaluable content would vanish over time justifiably, but then it's not really a, "Permanent Web."

Edit: Apparently I can't reply to your reply to this comment, but thanks for the link. I hadn't seen that.