> But you don't gain much, there's not a lot of weight to slow down with an ebike so regen gives you very little back.
But by the same token there's not a lot of weight to accelerate either, right? So while a moving bike has much less potential energy to recoup than a car, it needs much less to get back going again also.
So IMHO regen on a bike should be as useful as it is on a car, no?
>But by the same token there's not a lot of weight to accelerate either, right?
Right, most of the energy is used pushing air out of the way, which you don't get back from regen. Say you ride half a mile before stopping, the time to accelerate to 20mph is pretty small compared to the time you spend cruising at 20mph pushing all that air out of the way.
> Right, most of the energy is used pushing air out of the way
That's certainly the case once you're at speed (above 20km/hr is about the point where more energy is spent overcoming wind resistenace iirc). But I'm taking about taking off from the lights. Even to get you to 10 km/hr for free (or cheap) would be a bit boost for a commuter.
I’m surprised that nobody has mentioned Web MiniDisc yet. This combines the best of web (WASM) and MiniDisc, allowing you to write content to discs from the comfort of your web browser and dispense with all of the awful Sony software.
Web MiniDisc has added new life to the format. It lets you manage the contents of a MiniDisc ..from a web browser, thanks to WASM. Add MP3s, FLACs etc.
The irony of Google purporting to protect users' privacy while at the same time:
- Chrome is still shipping with 3rd party cookies turned on by default (Safari and Firefox have them off, by default)
- Chrome usage stats are sent to Google including button clicks. This is admitted in the Chrome privacy policy.
- Chrome on mobile automatically shares your location with your default search engine i.e. Google
- Chrome sort of forces a login …which shares browser and user details history with Google
- Google redirects logins through the youtube.com domain to enable them to set a cookie for YouTube as well as Gmail or whatever, every time you login. Naughty stuff.
So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on.
It amazes me that more people aren't calling Google out on this.
> So the stated reason for the change doesn't appear to make sense, suggesting that something else is going on.
That's unsubstantiated and dilutes the discussion IMO. If you read the post, the proposal outlines a bunch of good reasons to stop supporting UA strings (feature detection, etc)
> - Chrome sort of forces a login …which shares browser and user details history with Google
This doesn't get more true by just repeating it over and over. If you login to Google it'll show up in Chrome next to the address bar but it doesn't enable any syncing to Google servers. That's a different step and it requires opt-in. You can also use Chrome without logging in to any Google services.
I don't get why privacy advocates, who often have a point when talking about Google, have to rely on FUD.
Invasion of privacy is a valid and serious concern. The fact is that Google is collecting sensitive information semi-consensually and semi-transparently and arguably shouldn't be.
Because let's be honest, most "privacy advocates" on HN are trying to be purer than the other guy. Ideological purity is what they're after, not privacy.
Anyway, Google is a big company. Different teams have different priorities. Does the US government care about privacy? Depends - at the very least - whether you're the NSA or the FTC. Given the many signs in the past that parts of Google are willing to fight other parts of Google they disagree with, I think a better strategy for us as the community is to call the Chrome team out, specifically, on things under their control and otherwise not be excessive cynical about the fact that they along a hundred thousand other people work for Google, and some of those other people are bad.
(Automatic login to Google is a think I think we should call them out for, to be clear.)
It’s pretty silly to claim that the (admittedly bad) privacy policies of Google, or even Chrome, as a whole means it “doesn’t make sense” for any team within Google to advance a pro-privacy or pro-WWW project.
This all-or-nothing mindset ends up harming privacy in practice.
Google is not protecting its users privacy, it is protecting their own business. They want everyone's ads to be worse than Google's, so you use Google. Hiding private data from everyone but themselves is part of the plan.
Exactly. That is also why "logging in to Chrome" or rather Google is such an insidious misfeature. Soon they will be the only ones with cross-site tracking and third-party-cookie equvalents in the leading browser.
That would be check mate for all other advertisers.
I'm just not sure whether it's good or bad that antitrust regulators won't notice before it's too late.
I think that you're right. Regardless, these moves (as weak as they are so far) are beneficial for privacy in general.
I'll take that benefit even if it tilts the advertising table in favor of Google. I don't care even a little about the overall health of the advertising/marketing industry.
Tweet author here. Note at all of the responses from the site had a cryptomining script added, presumably due to a compromised machine. Our firewall just happened to notice the favicon first. So the favicon thing is just a coincidence and the browsers don't actually run the code in them (I checked this).
Tweet gives wrong picture, but only noticed afterwards when people replied. The site was mining Coinhive, but it wasn't the favicon that caused it.
I think that AMP as technical standard is OK in that it gives developers a format to follow that insulates them from the worst loading time issues that open-ended HTML can cause (JavaScript libraries and large images in particular). The performance gains are really significant e.g. 10x quicker load times on some sites.
The issue is how Google favours AMP results in search (with the lightening bolt and tag) and doesn't make it easy for users to get to the site hosting the page. We're sleep-walking into a kind of walled garden. More here: https://mobiforge.com/news-comment/sleepwalking-into-a-walle...
I have no problem with AMP--I've even implemented it on my sites. The issue I have is that Google is caching AMP pages on Google.com and never sending the traffic over to the site that originated the content.
This is true but bear in mind that you can retain a view of the traffic with any of the web analytics plug-ins supported by AMP (all of the major analytics providers are supported).
According to Steve Gibson (SQRL's inventor) tiQr is quite different:
"It superficially appears to offer a user experience similar to SQRL. However, as is every other such system, what's going on is actually far more complex and involves/requires establishing “shared secret” account credentials with the authenticating website. As they explain on their technical page, TiQr is based on the OATH (open authentication) OCRA protocol suite, which was standardized by RFC6287."
reply