It can help abstract the differences you may have across projects. If you're on a team with many projects/repositories, having conventions across them all helps improve onboarding, cross-teamwork and promotes better dev ux. A really simple way to do this is make. It lets you have the common targets and convert them to the relevant target. This can become more useful as you write automation for CI and deployments for all your projects.
Isn't this an implicit risk anyone who purchases a 'smart' device takes? Every company will eventually discontinue their cloud service for a product line when it suits their needs. We have seen this countless times in technology and that anyone assumes that cycle will repeat with all these devices is fooling themselves.
They might be tracking whether I'm logged in, but since I didn't log into the site I didn't consent for them to store that state on my client. The e-Privacy directive is quite particular, and unless these cookies are "strictly necessary" to operate the sandbox they're not allowed.
A CSRF vulnerability on a login form is a bit of a weird one: doesn't this require that the user has submitted their username and password to a site that isn't yours, in which case the attacker has successfully phished the user and can impersonate them or keep them on a proxy of your site?
(Spitballing: a standard way to implement CSRF protection with no cookies at all is when you generate the form you include a nonce. Then when the form is submitted you check whether it's a nonce you generated, which you do either by having stored it or generated it by hashing information you've stored. Implemented naively on a login form this would allow the attacker to fetch your page, extract the nonce, and include it in a cross-site request. But you could require it to be from the same IP. Alternatively I think you could fix this by having your login form set a custom header, which then browsers won't allow a cross-site POST for without a CORS preflight which you'd reject. But at this point I'm brainstorming and please don't take any of this very seriously!)
Why would you ever use a cookies to store a CSRF token? A CSRF token is a per request value and that's not what cookies are designed for. Generally the CSRF token is a hidden value on the login form.
In that case the cookie can at least be scoped to the login form with a Path attribute and limited to the current session, which these aren't. The cookies on https://sentry.io/auth/login/ set without user intervention are valid beyond the current browser session and two of them have durations of a year. One even has Same-Site=Lax!
(It's also not clear to me that cookies are required, if there are other technically sound options that do this without setting cookies.)
If you authenticate users only via Same-Site=Strict cookies you're protected against CSRF in modern browsers: a cross-site request won't have the auth cookie.
Session cookies are often encrypted by frameworks using a server side secret.
This allows storing data such as the CRSF token value to check against the one in the hidden form element or X-CSRF-Token without inserting in a DB every time someone loads up a form.
Note that to prevent session fixation, the session ought to be reset on a successful login (and logout), so it would require additional code to perform tracking across a successful login.
Session cookies are also used for Rails flash messages, commonly used to display errors in forms (including login forms), which often do HTTP redirects to GET routes in their non-GET controller actions.
The underlying subtext is that these session cookies can be a necessity of securing the provided service, and thus can fall under valid "strictly necessary" usage, as long as they are not abused for tracking (by default nothing in the session cookie is stored nor logged anywhere)
It might also just be done by whatever underlying web framework they use without them realizing. Like maybe a call to a method that checks if you are authenticated creates those cookies deep in some library they have less control / ownership of. Just taking a guess.
Possibly! But then they need to choose: take full control of their stack to where they can ensure it doesn't set unnecessary cookies, or use cookie banners.
If they're essential for doing what the user wants, though, then (a) no one cares and (b) they don't need e-Privacy consent and so don't need a cookie banner.
But you're thinking of it as an end customer. What if instead of a 'charging' station getting all the transaction fees the car manufacturers could haggle for some bps and work their way towards a controlling interest in this consortium.
Manufacturers want in because of all the potential $.
It might not be your thing, but I frequently use 'active listening to music' as a way to relax after a long day. I don't have ultra high end kit either. I'm doing most of my listening on entry level Grado headphones attached to my laptop. I have a hard time believing that I'm unique in this activity.
Why? We all have to pay for shelter and food. This looks like what could become a fantastic business and product. I applaud their commitments to privacy and open-source at such an early stage. I am looking forward to hearing about Notesnook more in the future.
Interesting, I've never seen this mode of firefox before. I checked a few other sites and they also had a 'Failed to load article from page' error. Do you have a link for a site that does work?
Sentry is not APM, when I last tested the product it looked like randomized tracing comparable to Datadog.
Edit: I looked at the docs, Sentry still has a sample rate parameter so this product can't give you the same results. With NewRelic I can have 100M transaction per day and then I have a single different transaction once every day and I can be sure that the agent will pick it up - always. With sampling you don't get that. Tracing gets you more depth but I seldom need that, I want APM and I only need tracing for a very very low percentage of transactions.
I run https://stickler-ci.com While it is not currently at 500/month but it has been there in the past.
I started this as a way to improve review speed at a previous position and it was well received, so I converted the prototype into a it's current form and have been running it for a few years now.