helper

Now we just need to get all the state government agencies to drop this requirement as well (looking at you, California).

Where's the button to provision more TGW capacity?

(2 days later) The status site now shows %99.9 uptime for the quarter.

That number is almost certainly updated manually. Check back tomorrow and see what it says.

If you look at the history page you can see its not 100% for every month: https://status.slack.com/calendar

Flashpaper is great if you have a trusted server and a trusted operator running it. Seriously, don't use a random flashpaper server on the internet if you want to keep your secrets secret.

Based on the screenshots it looks like the mac address is leaking out because its in the referer. I would guess this isn't intentional and shouldn't be hard to fix.

I've worked with a number of captive portal systems and they all basically work the same way. The AP/controller intercepts http requests and redirects to the captive portal page with identifying information about the device (ip,mac,ssid,ap_mac,etc.). The captive portal http server shows the user a splash page to accept terms or enter a username/password or a credit card. Once the captive portal server decides the user should be allowed onto the network it needs to communicate that back to the wireless hardware which is done with the user's mac address.

Based on the requests it looks like they have some ads/trackers on the splash page that are getting requests with a referer set to the original splash page url (which includes the client mac address). A no-referrer meta tag or an intermediate redirect would prevent this from happening.

What are the missing features?

I think hangout meet live streaming is supposed to be the replacement for hangouts on air[1].

[1]: https://support.google.com/meet/answer/9055488

Ugh, I honestly couldn't tell if this article was a joke or not (it seems to not be). The more you read the more absurd it becomes.

I've not heard of JPEG XL before now. Why would you name it that? XL certainly doesn't make me think "wow that sounds like way better compression".

JPEG Blockchain: come on! Are you really so worried about being relevant that you have to talk about blockchains in your press release?

JPEG AI: I could image that this is real, but I'm fairly skeptical of anything that is taking about machine learning and blockchains in the same context.

Its so unnecessary too. A 3x quality improvement is massive. Why not just let that speak for itself? This press release makes me hope just a little bit that JPEG XL loses out to WebP or HEIF.

Thanks for pointing that out. Thats what I get for not actually reading the proposal.

Yeah, don't deploy it when its in beta or its first few releases. At some point it will be stable and safe at which point everyone from then on will benefit.

As an operator, having fewer dependencies I have to deploy and worry about is a boon to my productivity.

If you were building a kafka like system in house for private use only, then yes I agree with your sentiment. If you are building something to be used by hundreds or thousands of organizations then the cost benefit tradeoffs shift to where it probably makes sense to pull the consensus logic into the primary application itself.

Normally you wouldn't write that since the compiler will be able to infer the baz type based on buzz (assuming this is a call to a generic function).

If you're just going to copy another language there really isn't much of a point in making a new language. Go is not java, or c# or rust.

Part of the explicit goal stated by the go team is that generics must still feel like go. If you slapped java generics onto go it would not feel like go.

It doesn't look like bpftrace is available in the default repos for Ubuntu 18.04.

MTA-STS prevents downgrade attacks.

> Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.

I think this comes straight from the original go team. Rob Pike had a talk[1] that is partly about why go doesn't keep adding features and why it doesn't have certain features that other languages have. I think people who like go have bought into the idea that the go team has made good trade-offs to make go code easier to read and maintain at the expense of expressibility.

[1]: https://www.youtube.com/watch?v=rFejpH_tAHM

Chrome has a dialog but it has a checkbox to say 'always open with this app in the future'.

This is a fantastic postmortem. Thanks jgc!

Can you share any more details about the protection to prevent excessive cpu usage by a regular expression that was accidentally removed?

I'm not saying that isn't true for some things. I don't think its true here given that this is a nice narrowly scoped library that does a single thing and has well defined semantics.

Adding a cgo dependency is generally something that isn't done lightly by teams. Having a port to go instead of a wrapper around go would be much more likely to see widespread adoption.

The c++ implementation is <1000 lines. Doesn't seem like a correct port would be particularly difficult, especially with a reasonably large test corpus.

I get 0.7 in both desktop (linux) chrome and firefox. I get 0.3 from android chrome.

I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other.

I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder.

Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams.

Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language.

I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."

Tavis didn't write the bug he just found it (through a lot of hard work). This was free security research given to Microsoft. He gave them a very reasonable amount of time before disclosing the bug (if the disclosure window was 180 days and MS missed it people would be complaining just the same as 90 days).

There's no reason why someone else couldn't discover this bug and exploit it. I would rather know that I am vulnerable then be ignorant and assume my software was safe when it in fact was not.

Thanks taviso for all the great security work you do. (Also 2004 me would like to thank you for your cool fvwm configs).

I've seen that behavior using chrome on linux when using public wifi networks.

Johns* Hopkins.