diafygi

Most meatspace laws are expected to be followed despite there being little to no physical barrier to breaking them (e.g. there's no physical barrier preventing me from throwing a brick through a window, but it would still be vandalism).

Why should we expect laws in software to be different? Why should the burden of compliance be shifted from the individual/company to the infrastructure?

You don't have to use their app for day-to-day usage via Bluetooth, however, they make it impossible to initially setup noise canceling functionality without the app.

I'm extremely grateful that the Bluetooth protocol is broken up into specific functions, so I know that if I connect my headphones/car/etc. via bt audio it can't also send data to the cloud through my phone.

Also, I really wish you would be able to specify which container you want in the Home button when using multiple urls for your default tabs.

So this:

    https://gmail.com/|https://gmail.com/

    {container:personal}https://gmail.com/|{container:work}https://gmail.com/

The spec says, "If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code."[1]

If an authorization server implements the recommended behavior and an auto-redirect, doesn't that mean that GET requests will no longer be safely considered immutable since they may cause revocation of previous access_tokens?

[1]: https://tools.ietf.org/html/rfc6749#section-10.5

A client should usually only redirect the user to the OAuth authorization endpoint when:

(a) they don't have an access_token (e.g. they haven't asked for authorization yet)

(b) their current access_token or refresh_token got rejected (e.g. the resource owner revoked access, so they need to reauthorize)

(c) they want to change scope of access

So the situation where you redirect the user to the OAuth authorization endpoint when they've already granted access and with the same scope is usually when something strange is going on (like when the client loses your access_token or this exploit happens).

So why would you have different behavior (not asking to click Authorize) just to streamline the atypical scenario? Especially when it leaves open the possibility to be exploited[1], create confusing situations[2], or be mis-categorized as an opt-in event when it isn't[3]. As a user, I'd like to think that I'd always get the same behavior every time I'm redirected to an OAuth authorization endpoint, because the OAuth provider doesn't have any idea what the situation is on the client side and assuming it's okay to auto-redirect without asking for my consent again is dangerous.

[1]: This HEAD bug would have not been able to be exploited in the wild if the auto-redirect wasn't in place.

[2]: In clients that allow users to have multiple accounts (where each can hook-up a github connection), auto-redirects creates confusing revocations across the multiple client accounts. For example, Bob authorizes a github connection to account A, then when he switches to account B wants to authorize github again. If auto-redirect is in place, then Bob wouldn't see anything (since it is a transparent redirect), but account B's connection would start working and account A's connection would silently stop working. If there were an authorize click, Bob would see the same behavior for account A and account B, and probably be able to put together that if he clicks authorize on one account, the other stops working. Auto-redirects makes Bob figuring out what's going on really hard.

[3]: Privacy regulations are requiring opt-in more and more, and OAuth is seen as a fairly good mechanism for proving someone "opt'd in". If a regulation requires a "consent" to have an expiration (e.g. an accounting app must require the user to re-authorize bank access on a yearly basis), then when the users is asked to "consent" again, if they get auto-redirected, they can later claim they were never asked to consent because they never clicked authorize again after a year.

1. Send an ajax HEAD request, which grants the permissions.

2. However, since the HEAD response doesn't have valid CORS headers, you can't read the 'code' parameter from the HEAD response.

3. To get around CORS, the proof-of-concept redirects the user to the same OAuth url again.

4. Since the user has already authorized the scope (from the previous HEAD request), Github automatically redirects back to the redirect_uri (the proof-of-concept page) with a new 'code' that the author can then use.

So I have two questions:

a) If I have 3rd party cookies disabled, will the "credentials: 'include'," part of the ajax HEAD request still work?

b) Why does Github automatically redirect back the 2nd time without asking the user to authorize again? I thought it was best practice to ask the user to click authorize every time even if they're authorizing the same scope they previously authorized?

[1]: https://not-an-aardvark.github.io/oauth-bypass-poc-fbdf56605...

For software, it feels like we're only at the beginning of understanding the dangers and consequences of the software, business models, and technology our industry has created. Unfortunately, if it follows the same path as other engineering disciplines, we likely will experience decades or centuries of bloodshed before it is regulated appropriately.

For database migrations, we (1) design them so they can be applied without breaking the existing app and (2) make a "pre-launch" commit that adds those migrations to the codebase but doesn't have any code that uses them yet.

To deploy, we merge the "pre-launch" into "prod" and deploy, and since the app doesn't use the new db changes yet, it will happily continue working fine. Then, at our leisure we can manually run the migration (either through the framework built-in migration tools or manually through the db shell). Then, we can merge the full "launch" branch into "prod" and deploy again, which will push the code that starts using the db changes.

To roll back, we move "prod" back to "pre-launch" and deploy, which moves the app back to the state where the code isn't using the db changes, but the changes are still expected to be in place. Then, we manually roll back the migrations using the reverse of whatever migration method you used originally, which is fine since nothing in the codebase in the "pre-launch" commit is using the db changes. Then, we move "prod" back to whatever commit we need to roll back to and deploy again.

It takes a bit of planning and forethought, but it means no downtime and you have all the time you need to manually apply and roll-back db changes that can take a while (adding indexes to huge tables, etc.).

Rather than trying to challenge them on whether they really do have anything to hide, I usually try to challenge their assumption that privacy is an individual right. Privacy isn't an individual right. It's a societal right. It's there to ensure those who want to make change can effectively organize, which is necessary in a democratic society. So you have the right to privacy whether you like it to or not, because society needs it. Keeping your individual porn habits secret is a side effect.

People who tend to argue, "I have nothing to hide," usually think well of themselves. So if you can get them thinking of privacy as a social good, more "we" than "me", then you can show them that supporting privacy protections is more of an altruistic gesture than a vice.

If they want a specific example, the I usually talk about women's suffrage. It's only been 100 years since women didn't have the right to vote in the U.S., and suffragettes were extremely effective in 1919 by organizing privately then showing up in mass to overwhelm legislatures and mount demonstrations that couldn't be silenced or hidden. If lawmakers knew about all those damn women organizing such big events, women likely would not have been successful at getting the right to vote.

Privacy is the lubricant that lets society move, whether it's pro-life movements, pro-pot movements, or any other political movement. They all need privacy to actually be successful.

However, everyone I know in the space looks at that challenge as opportunity rather than discouragement. It's not like we're going to hit high penetrations of intermittent renewables overnight. It's going to be a gradual ramp over years that allows us to also deploy complimentary systems to deal with the ever increasing intermittency. Piece-by-piece we will deploy flexibility technologies (DR, DERMS, storage, etc.) and move to new regulatory incentives and utility business models (performance-based ratemaking, etc.) that allow us to reach our 100% goals.

There's a ton of super smart people already working on the intermittency problem, and entire businesses are being built to solve it (disclosure: many of them use our platform). So I guess while I agree with your assessment of the level of difficulty, I don't agree with your level of despair. There's way too many smart engineers working in the space now for intermittency to be in impossible problem to solve.

First, it's way easier and faster to just park containers full of batteries wherever you need to shift the energy than to find and build new pumped hydro location then build/upgrade the transmission to the locations where the load shifting is needed. And when you need the load shifting ASAP, you're probably going to opt for the solution that can deployed now, especially when the regulatory reaction to this problem is to adjust prices ("time of use" rates) to discourage people from using power during the slope.

Second, battery installers are able to sell directly to consumers, which means they can bypass utility bureaucracy. Many utilities are very slow to adopt "non-wires alternatives" because their business model doesn't incentivize them to building out a distributed, flexible grid, and they are increasingly becoming worried about their generation assets being financially stranded. This means that it's often easier to sell thousands of energy storage units to thousands of homes and businesses, than it is to sell that same thousand units directly to the utility. With pumped hydro, there's no distributed option, so you end up being at the mercy of the utility wanting your product.

So yes, you're probably right that pumped hydro is on paper cheaper for addressing the Duck Curve "neck" problem, but this is a case where the difference between theory and reality is substantial for non-technical reasons.

I'd also like to point out that the Duck Curve is a good example of the class of problem in the energy transition that seem like a major blocker at first and is often pointed to by detractors to using solar energy, but isn't really.

Since these types of problems take years to manifest, it can be being broken down into smaller prioritized problems (such as addressing the slope problem of the "neck") that we, the cleantech sector, can individually figure out and deploy solutions to without stopping progress decarboninzing the grid. If you just keep solving thousands of these smaller problems over time, eventually you'll end up solving the overall problem.

In a time where it's politically infeasible to do big things (e.g. building hundreds of nuclear generators), the cleantech sector has for the most part been making progress through incremental solutions that over time will get us where we need to go. I have no doubt that we'll solve the Duck Curve problem, but it will likely be one step at a time, not large strategic changes, which to outsiders make it seems like the problem is still a "blocker".

Anyway, this is what fighting climate change looks like, and as an engineer, it's tons of fun to know that if you just keep solving problems, you'll wake up one day in a 100% clean energy world that you helped create.

https://www.caiso.com/TodaysOutlook/Pages/default.aspx

The issue nowadays isn't so much the depth of the dip in dispatchable (e.g. traditional) generation, but the slope of the ramp back up after the sun goes down (e.g. the "neck" of the duck). Base load natural gas an other fossil generation have a very difficult time spinning up that quickly (CAISO said it was ~11GW over 3 hours yesterday).

That's why batteries are such a hot topic in renewables right now. Not so much for storing power for "a rainy day", but for helping load shift during the day to prevent such a steep slope in the evenings. Lithium is pretty good at doing that kind of short, daily-burst storage job.

If you process the feeds for public transit security cameras, I wouldn't be surprised if you can read the pin codes for a huge swath of the population. It would also reduce the need for law enforcement to try to get a suspect to tell them their passcode. Just look up that time they rode the subway 3 weeks ago and watch them enter it.

The only self-hosted one I can find that has a funnel feature is Matomo.

Speaking of, are there any UI/UX design resources (books, tutorials, blog posts, etc.) on for modern authentication flows (2FA, OAuth, etc.)?

I've been searching for a while and can't seem to find anything substantial. All the design discussion I can find is around protocols/handshakes/security, but nothing about UI/UX best practices and possibilities.

My point was that how you receive someone saying YC changed their life is highly dependent on whether you think that the result should be celebrated or emulated. Everyone has experienced things that changed their lives and the lives of those around them, so to someone who doesn't see VC success as very desirable, it comes across as a fairly weak argument.

Will cheap motors + cameras + software eventually meet or exceed the quality of expensive high precision motors/controllers?

Your carbon footprint is determined by how much carbon you're adding (e.g. burning gas that was previously sequestered deep underground) to the carbon cycle.

I suppose if a bunch of plastic got burned in the forest fire, that would technically be adding a carbon footprint, but it's likely negligible.

"Examples of cookies that generally do NOT require consent: ... Authentication cookies ..."

Also, even if you're correct in needing to have a cookie consent, you're still missing the decline option.

Finally, and I say this with all possible respect as a fellow entrepreneur who completely understands that you are pouring huge amounts of time and effort into this, your response was pretty inappropriate by being so emotionally charged. You sounded personally offended and reacted by lashing out and attacking the criticizer. As a startup, you're going to encounter that kind of criticism very often, so I'd suggest you find a different way of responding to it.

[1]: https://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#s...

Not a great first impression...

Correct me of I'm wrong, but you only need that box if you share cookie data with third parties, set third party cookies, or use cookies for non-primary business purposes (e.g. not just a session token for logged-in page authentication). So seeing any sort of a box like that indicates that you're going doing something nefarious and against the key differentiator of your product (privacy).

Also, the fact that there's no option to decline is a big giant red flag.

> Some of the top-level indicators are surprisingly healthy. HTTPS adoption has taken off like a rocket, driven in part by Google’s willingness to use it as a signal for search rankings — and the rise of free Certificate Authorities like LetsEncrypt. It’s possible that these things would have happened eventually without Snowden, but it’s less likely.

> End-to-end encrypted messaging has also taken off like a rocket, largely due to adoption by WhatsApp and a host of relatively new apps. It’s reached the point where law enforcement agencies have begun to freak out, as the slide below illustrates.

The engineering and technology culture around security and product development has certainly changed. The IETF even adopted "Pervasive Monitoring Is an Attak"[1] as a best current practice.

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

How can NPR not ultimately be captured by corporate interests with for-profit sponsorships?

Most people in this thread are saying, essentially, "Fool me once..." But I'm curious to know if engineers internal to Facebook are aware they are in the same situation, where the privacy assurances by the company will eventually get usurped by its thirst for data. Or do you acknowledge that will happen and just see yourself as a mercenary?