sayhello

Counter-Strike was a mod of Half Life, not Halo.

When I was a Google employee, I helped a friend go through their account lockout issue. It was because they used MFA to a phone number, but later changed their phone number, which made them unable to login. He tried so many times that some velocity threshold was hit, further limiting the possibilities.

My friend needed to respond to some interview scheduling, so, it was a stressful situation.

Part of the problem was that it was hard for my friend to find a way to create a support ticket. He did in the end and got in a line of communication via an alternate email.

There were many miscommunications from both my friend and the support agent. While Account Recovery or even basic identification are hard to navigate for technically-minded folks, it's even more challenging for non-technical folks, including the support agent.

In the end, I got in touch with the support person, helped translate what they wanted to know to my friend, and likewise, translated what my friend was saying in a way that the support person could understand.

I don't think I was able to see the support ticket itself, because of PII restrictions. In the end, my friend was able to restore service. I doubt he'd have been able to without my support in time to respond to the interview scheduling.

It still took a couple of days.

The three-body problem.

https://en.m.wikipedia.org/wiki/The_Three-Body_Problem_(nove...

We made sure that the activation of the API is gated by:

1) User Activation checks 2) When access to the file system is requested, a File Picker is necessary 3) When the API is in use, there are plenty of indication that it's being used

We put a lot of thought in Privacy and Security, as we do for all APIs.

Precisely. You'll also gain the ability to update your apps cheaply (via the web) and bonus security points by not being beholden to Electron updates.

I worked on this. The quote is true, in all honesty. Same as downloading and running applications from the web.

We do our best to make sure the scenario listed doesn't happen. For instance, on Windows, after a writer is closed, we apply the Mark-of-the-Web, apply SafeBrowsing checks and finally call a system API which may trigger an anti-virus check.

On the Mac, we apply the equivalent of Mark-of-the-Web. You may have noticed that when you open the file, sometimes it asks you to ensure the provenance of the file?

Basically, it's a similar procedure as for file downloads.

Edit:

I forgot to say that "sensitive" directories are not allowed. Think C:\Windows, etc.

https://source.chromium.org/chromium/chromium/src/+/master:c...

Why does it have to be sad? When software becomes easier to develop, it enables everyone to benefit.

More developers, more applications of software.

At the same time, performance has a tangential relationship with computer code being interpreted or compiled to native.

After all, Java is compiled to byte code and powers plenty of high traffic servers efficiently.

Many AAA games use ActionScript, Python, Lua, etc for their UIs and scripting for mods.

While it's true that there is no substitute for code compiled to native when high performance is called for, I think it's justified for native development to be last resort.

This is coming from someone who codes primarily in C++, where high performance is important. I wish I didn't have to.

I beg to disagree :-)

I’ve worked on the Native File System API on Chrome.

It’s available through Origin Trial at the moment.

That said, Web apps can currently emulate reading files and writing to disk.

Take a look at this library, which also works as a poly fill:

https://github.com/tomayac/browser-nativefs

And it's nice that the web app only has a narrow set of permissions.

You could imagine the same for an unzipping app. It theory, an unzipping app doesn't need anything else than specific file system permissions, i.e. read for a specific set of bytes and write access to a specific filepath.

https://github.com/GoogleChromeLabs/unarchiver

I work on the Capabilities team on Chrome and I think it's pretty cool the web can do more, and provide safe experiences for users.

About web APIs, didn’t want to imply that blink was used instead of WebKit for that reason, it was just an example that rendering engines could still evolve independently.

Disclosure: I work at Google on Chrome. Opinions are my own.

Using chromium as a base, browsers will have to differentiate by offering a better product.

“Better” is less likely to be better performance, compatibility, or accessibility.

By using much of the same code as another browser implementer, any browser vendor [hint hint] that still makes their own engine could reduce the resources they put on the foundations and web platform and put more of it on the product itself.

Perhaps we’ll have more groundbreaking innovations to move browsers forward. The last few big ones: multi-process architecture, tabs.

In effect, by using the same foundations, the browser wars could in fact be reignited and the users could be the winners.

On the web platform side, I.e., the stuff you see on MDN and w3c specs, using the same “base” doesn’t mean the browsers won’t have different implementations of future APIs if the vendors’ opinions diverge strongly. Case in point: Chromium used to use WebKit as its renderer and now uses blink, a fork of WebKit.

Because the scammer may be using this as a way to launder money or to extract money from stolen credit cards.

They may not be scamming legitimate bookers, but rather, using the listing for other kinds of scams.

Good point. The current widely used kernels seem to make some assumptions about ‘owning’ the hardware and implicitly trust any running programs at a certain level.

There is a need, however, for some pragmatism.

While a capabilities-based OS could be the right solution, it doesn’t exist today.

What we have is code built for some flavor of POSIX. People demand cost efficiency today.

So, engineers do what’s practical: build a multi-tenant system running code that expects to be the owner of the hardware.

It works good enough! For most people, the cost efficiency math works out. The sand boxing overhead is worth it, as it pales in comparison to the headcount required to manage your machines, or even VMs, if you replace them with Serverless products.

Did the BSD jails provide enough isolation? Would memory from a process truly be isolated from another? How about FD’s?

Could there be side channel attacks? At what level?

Perhaps the whole kernel design needs to be revisited, which I assume is what’s being taken on by Fuchsia.

Did the Windows Server isolation bundle a slim kernel?

One of the core elements of this for the Serverless fast boot requirement is using a kernel that has legacy modules excised.

Used to work on 2nd gen AppEngine.

I helped ship the runtimes!

Yes, this is due to age. GAE and Run depend on pieces of infrastructure going back a long time.

Google has an office downtown. They've got a growing engineering team too, mostly in Cloud.

As an engineer working on App Engine, I can assure you that's not true.

We've been changing a lot of infrastructure, adding features, fixing bugs, all without users being affected.

I'm personally very excited about the Second Generation Runtimes, which have been worked on in parallel, and run the runtimes unmodified.

More runtimes coming out soon. Stay tuned :-)

Correct. We do not use ptrace in production.

I made a logical error, I meant to say:

> the word does deny something: possibly objectivity.

i.e. there is a possibility of bias.

That said, I've made my peace about the "proper" use of language, or rather, the lack thereof, and now espouse it.

Like, literally.

The meanings of words and idioms shift over time. As long as we're understood well enough, that's fine by me.

I suppose colloquially on this forum in the context of comments, the word does deny something: usually of the possibility of bias.

Disclosure would work just as well, and is in fact more accurate!

This is exciting because the second generation standard environment allows Google App Engine to provide a more "idiomatic" experience.

Using gVisor, instead of NaCL, as the sandboxing technology, shipping new runtimes becomes a much more tractable task with less differences from the "plain" runtime. In fact, gVisor allows us to use the runtime unmodified.

This in turn, decreases the "lock-in". There are still decisions we need to make depending on the runtime, e.g. which package manager to use if there isn't a community default.

Hopefully, the narrative for "Serverless" moves beyond lambda and functions. Sometimes (!) we want apps, databases, caches and more to be "Serverless" :-)

Disclaimer: I work at Google, on the App Engine Runtimes team. I helped ship this

Not stopping at a stop sign is called the “Idaho Stop”.

https://en.m.wikipedia.org/wiki/Idaho_stop

It is legal elsewhere. Two studies argue that it seems to increase safety on the road.

Stopping when street cars stop is a must, however.

Exciting release of the 2nd generation of App Engine runtimes. I'm really excited to see how the community receives this product.

It uses the gVisor sandbox, allowing sandboxing at the process level. This in turns allow for fast turning up and scaling of apps.

Disclosure: I work for Google, on the App Engine Runtimes team.

Might be hardware related. Did you provide your HW profile in the bug report?

(Disclaimer: I work at Google, though on unrelated things. Opinions my own, yada, yada)

Worked at a privacy obsessed place before (Mozilla) where I worked on building privacy-preserving ad infrastructure.

I think we've more to fear about the other data brokers (so-called DMP's and their sources of data, e.g. your bank) than Google. At the very least, we have some assurance Google is competent with handling the data.

Google is a big well-known target and definitely poses a central point of failure for our data, but this piece could've been more than a dig at Google and rather, could have explored how private information is handled in the Ad industry in general.

I have a Leesa and liked it so much that I bought 2 more for the rest of my beds.

It feels great for me, I like a firmer mattress, but it’s not too firm.

Here are the highlights:

1. Half the price of the equivalent at Sleep Country

2. Didn’t have to deal with mattress sales people. Margins are so high there is usually a negotiation. Given the varying types of materials, I don’t really know how to price and why I should bother knowing the ins and outs of mattresses. I don’t like the upsells. Makes it feel like going to a car dealership.

3. Shipped and got delivered fairly fast.

Cons:

1. Buying it sight unseen can be unnerving, especially for a $1,000 purchase. I guess that’s why they have the generous return policy.

2. Differentiation. I don’t know how Casper is different from Leesa. I went on a review site and trusted it, I guess, but even then, they seemed to be made the same way more or less.

NESticle was a fantastic emulator; it really upped the ante as far as user experience went.

It was fast, had way more capabilities and configurability than others.

The UI was polished and dripping with personality.

At the time, while I had dabbled in making small BASIC programs and hex editing games to bypass copy protection, I didn’t know it would even be possible to emulate a whole computer system, and to do it with such aplomb.

It inspired me to delve deeper in the scene and probably played a role in me to take an interest in software development as a vocation.

Firefox is probably slower because it uses the javascript implementation of the hashing algorithm:

https://github.com/nimiq-network/core/blob/master/src/main/p...

Chrome implements the WebCrypto API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...

I think it uses this interface: https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...