fwupd updated my Logitech "Unifying" receiver firmware :-) And Dell uses it to provide updates of some of their laptops and servers.
42 karma · joined August 3, 2013
fwupd updated my Logitech "Unifying" receiver firmware :-) And Dell uses it to provide updates of some of their laptops and servers.
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.
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.
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.
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.
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.
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.
- 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 :-)
Doesn't meant it is not true, but I am not sure you can claim that this article is endorsed by CNN.
if the CSS isn't needed immediately, simply don't load it :)
No need to do browser detection. Just make your site work without JS as well :)
```
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/).
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/