Splines

> Now it started again but this time the power management tools report no reason for the wake.

I ran into this after building a system and it was very frustrating. IIRC my problems were related to my network card and having virtualbox installed. Also turning off wake for my mouse helped (bumping the desk would turn on the computer).

> No one would rely on this to keep actual sensitive info private, since you can just screen shot it.

It's more of a "please don't forward this" feature than a "you can't forward this" feature. It's the same with DRM features in Outlook. It stops people from accidentally leaking information, but it doesn't stop people who intentionally want to leak information.

In an ideal world telling the recipient not to spread this information (either by just asking or some kind of work policy) should be enough but sometimes having a small technical barrier is needed.

Also when information is leaked at a later time it can show intent on the leaker (vs saying something like "oops I fat-fingered the recipients when I forwarded that email to my personal account")

I think the difference between autopilot and other safety innovations is that the failure state of autopilot is rather spectacular (maybe it's closest to seatbelts/airbags in this regard). When it works, it's great. When it doesn't work and causes harm, it's easy to point to as a reason not to use it.

A lot of the other car-safety innovations usually have a failure state where it doesn't put you in a worse off position that you normally would have been in, should that innovation not have existed (e.g., crumple zones, crash-safe interiors, highway design/signage, ABS, etc.).

Reducing the absolute # of car deaths is always a good thing, and undoubtedly # of deaths saved by AutoPilot > # of deaths caused by AutoPilot, but looking at that comparison makes people worrisome, especially if you can picture yourself on the RHS of that equation.

Personally I'm not sure where I stand. I do find it uncomfortable having ever-increasing levels of software complexity in my car.

It's surprising that this isn't the standard right now. I'm certain the people at Tesla/Uber/Waymo have considered this - I'm curious why this approach isn't more common.

> If you don't provide a way in the emails to say "that's not me", then I have no way to ever register for your service with my address.

This happened to me - someone registered an Uber account with my email address. So I password reset it and now I have an Uber account for no good reason.

> Hammer the Netflix signup form until you find a gmail.com address which is “already registered”. Let’s say you find the victim jameshfisher.

The bug is right here - you shouldn't be able to determine if a user account already exists.

If an account already exists:

- Logon shouldn't tell you that you have an account and the password was wrong

- Registration should send a "looks like you already have an account" email to the recipient with "maybe this wasn't you" warning, and the web form shouldn't indicate anything out of the ordinary.

- Password reset should say "if an account exists, we just sent it an email"

> Of wrong comparisons: you should check the autopilot against a rested and concentrated driver that drives slowly and with a lot of care. Since in the statistics otherwise you do not account for the fact that when you drive, you are in control, and you can decide your level of safety. Such a diligent driver that goes to crash because of an immature software is terrible.

Do these car companies test their software by just leaving it on all the time in a passive mode and measuring the deviance from the human driver?

I'd think that at least in MV case, you'd see a higher incidence of lane following difference at this spot and it would warrant an investigation.

Something like this isn't easy but for a company as ambitious as Tesla it doesn't sound unreasonable. Such a crash with such an easy repro should have been known about a long long time ago.

Mastodon can help you with the first part - you own the server and all the data on it. AFAIK there's no encryption of data at rest so you'd need to add that, but if you own the server it's less of a concern.

Totally agree. This is a problem I have in general with linux - you don't know what you don't know, and using man to find a command to do the thing you need is akin to using a dictionary to find a word to describe a definition you have.

The thing is that Steam was a vastly different way of distributing software at the time and offered benefits that drew customers to it. Using Linux has few practical benefits for most people other than cost savings of not buying Windows. And not many people explicitly pay for Windows either - it usually comes with the machine they bought.

I usually prefer apps too but it's only because apps have native controls that are first-class citizens in the UI - they don't float around and aren't as prone to being mis-clicked. Apps generally have better performance than the website too.

Sites that have more static text with large text controls are fine in the browser, but that's usually the exception.

Right? Maybe I'm not explaining very well. I feel like we're agreeing.

Checking a bit and discarding at collection time is the easiest. You need to ensure data collection is aware of this setting, and anything that manipulates this data doesn't need to care whether or not some data is "hidden" or not.

> That doesn't sound foolproof at all.

Right - If you go the route of collecting all data and hiding it later then all tools that interoperate with customer data need to make sure they don't accidentally expose "paused" data back to the customer.

Given two choices of throwing away data at collection time, or forever in the future trying to hide data from the customer, it seems simpler to throw away data at collection time.

I don't have any evidence whatsoever but I speculate that between the options of:

1. collecting data and hiding it during times it was paused

2. checking if data collection is paused during collection time and keeping it/throwing it away

Option (2) is the easiest and most foolproof. For (1), all it takes is a single tiny bug in any code that handles your data history and their whole privacy stance is shot.

I don't want to be a FB apologist (I uninstalled fb/messenger because of all this), but the text of the prompt seems relatively clear:

> Continuously upload info about your contacts like phone numbers and nicknames, and your call and text history. This lets friends find each other on Facebook and helps us create a better experience for everyone.

https://fbnewsroomus.files.wordpress.com/2018/03/opt-in_scre...

Granted, those six words are tacked on the end of a sentence, and given the intrusiveness of the feature should probably have been called out in its own opt-in dialog with its own switch. But it's not like they asked for contact access and turned around and used it for something else.

Maps is the only thing I rely on - I would be welcome for a replacement.

Stores do this already. Signs which read "Restrooms for customers only" are not uncommon.

Interesting insight. While self-driving cars should reduce the number of accidents, there are going to be some subset of people who are excellent drivers for which self-driving cars will increase their accident rates (for example, the kind of person who stays home when its icy, but decides that their new self-driving car can cope with the conditions).

Reminds me of this: https://www.youtube.com/watch?v=Sr1ym96abkg

True enough, but how much revenue is FB bringing in on these platforms? These platforms all have alternatives and aren't exactly sticky. If FB turns the screws to increase ROI, customers are going to leave.

> Epic is absolutely SWIMMING in money thanks to what was essentially a weekend project by two of their engineers.

Are you talking about Fortnite in general, or the Battle Royale mode?

The weird thing is that my impression is that Fortnite was talked about for awhile as this Horde-mode construction game, sort of like minecraft meets L4D. Then the BR F2P mode was added and the whole thing blew up.

What's the engineering tradeoffs required for windows? Would eliminating windows result in a safer, cheaper car?

Would projecting the outside world on the inside of a tin-can car meet the benefits ascribed to windows? (I could imagine some dystopian future where windowed cars are considered to be luxury items).

The amusing thing is that retailers are going to have the data that shows this works. Return fraud will certainly go down.

What they're not going to have is data on the people who choose not to shop at these stores because of this policy, both those who have been incorrectly identified as fraudsters and those who just don't want to bother with the hassle.

There is very likely a person or group at Amazon that considers this a feature, at least when product commingling was introduced.

In an ideal world with no counterfeits, product commingling is an efficient thing to do, and if a product is commingled, there is no point in giving the 3rd-party seller top billing, the customer should feel like they're buying from Amazon.

It seems like a harder problem than that as well - you might want some of the units in the back of the swarm to go the long way because they'd wait a long time at the choke.

But maybe you don't want to do that - those units in the back are squishy and need to stick with the units at the front of the choke.

But maybe that's ok - the alternative path isn't too far away and it's not a risky move to make.

Maybe that's too complicated. Probably best to make the swarm operate as if other moving units don't exist (to make pathing predictable) and let the player micromanage via waypoints/grouping.

If the fact that a name gets attached to the prize is the only thing stopping them, then they could easily make up a name and photoshop a picture. This feels like it's getting into conspiracy theory territory.

But how does making the winner's name public avoid fraud? I assume the government needs to look at something and say "looks legit". So couldn't they do that in private? Have some judge or gov't official put their stamp on it and say "yes, the winner was a real person not affiliated with the lottery" or whatever needs to happen.

Youtube gets this right and puts the content first, on all endpoints. I see a youtube video and click it, I get a video.

If I see a facebook link, there are many problems:

- I don't know if it's a video

- I don't know if I'll see a login page or if I'll get to the content

- I don't know if the content is viewable by me because of privacy settings

And then this works the other way - why should I share a video on facebook when I can't tell if my recipient will be able to see the video? I don't know if they'll get a login prompt. I don't know if they have the permissions to see the video.

All this friction doesn't exist with youtube, or at least is extremely minimal.

IMO Facebook video is a non-starter because of branding. Facebook is not a destination for video.

Facebook is to video as youtube is to social networking.

> Which implies that Uber needs to start off it's plans to build driverless cars from zero

What does this mean in a practical sense? rm -rf /car? Can the Uber engineers who worked on this continue to do so, or are they "tainted"?

This is an interesting strategy. The "build a service for internal use, then make it a service" strategy worked for them with AWS and web stores, but it failed for Amazon Fresh (but they are trying to turn it around with Whole Foods), and now they're trying again with shipping logistics.

Personally I've found them so-so, and certainly not great. I frequently get calls from drivers that are lost that can't find my new-ish street and need some help. It's certainly fine that the first one gets lost, but when the second one gets lost it's apparent that the organization isn't building up any knowledge about hard-to-find customers. This is a moat they could build, but they're not interested.