HN user
This already exists, https://fwupd.org/ It is strange they don't mention this and use it.
fwupd updated my Logitech "Unifying" receiver firmware :-) And Dell uses it to provide updates of some of their laptops and servers.
So, next step is DRM for webpages/content in addition to video, either you see all or nothing. The W3C is probably already running with the idea to destroy the "free" web :-)
https://developer.schiphol.nl/apis/flight-api/conditions
Has some serious restrictions in its use. You are not allowed to "cache" the data for more than 1 day? Strange.
And of course you need an "API key". It is public data, just make it public. HTTP/HTML is also an API, just a bit more cumbersome to parse than JSON.
It seems to make more sense to just have ONE that can accommodate all those scenarios in a secure way. One doesn't solve bloat by introducing more bloat.
I'd say more can be won by removing e.g. ASN.1 and X.509 for certificate handling and encoding that are a very difficult (impossible?) to get right and switch to something simple that solves the 99% use case of current TLS.
Actually. I realized that any party that would want to put their content behind this kind of obstruction does not really have anything interesting to show anyway. So better of without that particular content anyway! Same with sites that block you when using Privacy Badger. Good riddance.
The danger will be in it becoming normal for everyone to use EME, or that the most used audio/video devices and tools will by default enable this and make it hard/impossible to disable it. So if you shoot a video of police violence with your phone and decide to publish it that it can be blocked by e.g. government. Of course, pushing for integrating this with your video camera will be done to protect the children.
Not necessarily more smarts, but better tech means more affordable connectivity and education, and better education too.
This is not true. Neil Postman has something to say about this, already in 1996, in "The Surrender of Culture to Technology". It specifically mentions education and how the "wiring up to the information super highway" was misguided.
https://www.youtube.com/watch?v=hlrv7DIHllE
It is very interesting in reading/watching Maciej, Neil Postman and also Evgeny Morozov to put things in perspective.
The Google proprietary stuff, and some of the free parts in Android are also already spyware. But adding an additional layer of proprietary software is just no good for the user :-)
I mean, I can also rant about CyanogenMod using oCLock (or whatever it is called) that sends by default your exact GPS locations over HTTP (not HTTPS!) to Yahoo.
Allowing Samsung to put their own stuff on top will just not improve anything for the user, it will improve stuff for Samsung, but I don't care about that.
You make some good points, and it would certainly help somewhat, but it won't solve the underlying problem. Instead of real choice and ability to buy something that will be under your control instead of the manufacturer or operator you need more than giving Samsung et al the ability to remove Google Chrome and install their own browser infested with spyware that no longer receives security updates after it ships and cannot be removed. If these constructs Google enforces on the manufacturers are indeed illegal, why don't Samsung, HTC, etc. not sue Google to get it sorted? I mean, it is a b2b problem.
A Galaxy config? Yeah, they have that now more or less, they offer many alternatives next to the Google ones installed by default that are in all ways inferior to the Google versions of those apps. They replace one big company services with another and do a worse job. No benefit for users.
Anything that does not bring benefits to projects like e.g. Replicant or CopperheadOS are in the end meaningless for "consumer" freedom and progress in the mobile device space.
What I'm missing is a list of things that Google has to fix, that is in the benefit of the "consumer". It seems that most things that would be in the benefit of the consumer have nothing to do with Google, but with the shitty manufacturers that don't provide (security) updates and stuff their phones with crap. Things that would help:
- force manufacturers to have an AOSP build without Google Apps or any of their customizations, updated when needed (security, new major/minor releases etc.);
- force manufacturers to allow users to exercise the 4 freedoms (FSF) with the above AOSP build up to and including the baseband/firmware/drivers;
- allow manufacturers to do whatever they want for their default OS installed when the user buys it (possibly signing a deal with Google for Google Apps etc.)
I keep on dreaming :-)
They could just create 'share.wikipedia.org' and make that available so everyone can go there to share/distribute whatever files they want using a secret token they put in their FB group instead of hiding them in Wikipedia articles. No need to clean up articles anymore. With a nice retention policy to automatically expire old content it could actually work :)
About this iReport Not verified by CNN
Doesn't meant it is not true, but I am not sure you can claim that this article is endorsed by CNN.
I guess it is time for this one again: http://idlewords.com/talks/website_obesity.htm
if the CSS isn't needed immediately, simply don't load it :)
I love how they, in that example, use JS to load the rest of the CSS. Seriously?
https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Fault_tolerance
No need to do browser detection. Just make your site work without JS as well :)
https://tools.ietf.org/html/rfc6749#section-1.8
```
OAuth 2.0 provides a rich authorization framework with well-defined
security properties. However, as a rich and highly extensible
framework with many optional components, on its own, this
specification is likely to produce a wide range of non-interoperable
implementations.
In addition, this specification leaves a few required components
partially or fully undefined (e.g., client registration,
authorization server capabilities, endpoint discovery). Without
these components, clients must be manually and specifically
configured against a specific authorization server and resource
server in order to interoperate.
This framework was designed with the clear expectation that future
work will define prescriptive profiles and extensions necessary to
achieve full web-scale interoperability.
So what are we waiting for? I don't think OpenID Connect is the answer here, maybe something more in the direction of IndieAuth (https://indieauth.com/).
Ah, my point was, actually, to base the remoteStorage spec on WebDAV instead of a new JSON-based protocol as it currently exists. remoteStorage could define a WebDAV 'profile' for what needs to be supported by the server...
Full disclosure: I contributed to the remoteStorage specification [0].
Instead of (or in addition to) considering remoteStorage, one could also go back to "normal" WebDAV, if such a thing exists, and completely forget about the CalDAV/CardDAV servers.
I'd say WebDAV is more mature, it has litmus[1] for testing implementations. remoteStorage has as far as I know only one production instance running at 5apps [2]. The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3]. One thing missing from WebDAV is the (implicit) mapping of OAuth scopes to ACLs, which should not be too difficult to implement... The discovery, by depending on Webfinger, is also not one of my favorites. I'd prefer something like OAuth authorization server discovery [4].
I mean, I am not opposed to using remoteStorage and love JSON as much as the next guy, but it just doesn't bring (in my opinion) many benefits and loses interop with existing WebDAV clients for no good reason...
[0] https://datatracker.ietf.org/doc/draft-dejong-remotestorage/
[1] http://www.webdav.org/neon/litmus/
Proving (part of) the point of the article ;)
what is wrong with OsmAnd? Have been using it for many years already.
403 Forbidden Request forbidden by administrative rules.